In-memory metrics catalog

ABSTRACT

The disclosed embodiments include a method performed by a data intake and query system. The method includes populating each metric including a measure value, cataloging metadata in an in-memory metrics catalog, where the metadata is related to the metrics. The method further includes receiving a search query including search criteria, evaluating the search query by applying the search criteria to the metadata of the metrics catalog to obtain results that satisfy the search criteria, and causing display, on a display device, of the results or data indicative of the results.

CROSS-REFERENCE OF RELATED APPLICATIONS

The present application claims benefit of U.S. Provisional ApplicationNo. 62/400,081, filed on Sep. 26, 2016, entitled “ANALYZING AND STORINGMETRICS DATA”, which is hereby incorporated by reference in itsentirety.

COPYRIGHT NOTICE

A portion of the disclosure of this patent document contains materialwhich is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure, as it appears in the Patent and TrademarkOffice patent file or records, but otherwise reserves all copyrightrights whatsoever.

FIELD

At least one embodiment of the present disclosure pertains to storingand querying metrics data, and, more particularly, to improving thecapabilities of a data intake and query system to query the storedmetrics data.

BACKGROUND

An information technology (IT) ecosystem typically includesinfrastructures of various kinds of computing resources includingcomputer systems, servers, storage systems, network communicationdevices, or any other electronic resource having characteristics thatcan be measured. Measuring the characteristics of the computingresources is vital to mitigating instabilities and detectingvulnerabilities. Examples of the characteristics include temperature,utilization, availability, etc. For example, measuring the health of adatacenter's infrastructure, services, service components, backendsystems, and various types of application programming interfaces (APIs)is important to enable organizations to proactively monitor, diagnose,and analyze the infrastructure, application, and business metrics of thedatacenter.

The performance metrics (e.g., metrics) are useful time-seriesmeasurements of computing resources for IT operations and applicationmanagement. Metrics are used to analyze performance of one or moresystems in a domain. Specifically, a metric represents a performancemeasurement of a computing resource. The metric includes a numericalvalue indicative of a characteristic of the computing resource measuredat a point in time. The numerical value may also be referred to as the“measure” of the metric. In some cases, a metric can represent a datapoint of a time series of characteristic measurements taken of acomputing resource. The numerical value may be a floating point valueincluding any number of decimal values that reflects a precision of thatmeasurement. In some embodiments, the number can be an integer value.

Metrics can be measured at short intervals for multiple applicationsand/or systems, resulting in large data sets. Metrics measurements canbe at the root of everything deployed and managed in at least some knownIT environments. From on-premises to cloud deployments, measurements ofsuch metrics enable analysts to understand the availability,performance, and health of mission critical services delivered to endusers. Such metrics measurements can provide insights into trends andfacilitate a comparison of what is normal and what is not. Existingsystems for processing and analyzing metrics data remain inadequate andfail to provide meaningful insights into the health of computingresources.

Metrics can also be helpful in assessing machine-generated datagenerated by various components in IT environments, such as servers,sensors, routers, mobile devices, Internet of Things (IoT) devices,etc., and for business analytics and security. Analyzing large volumesof machine-generated data has become imperative to obtaining criticalinsights of systems and their computing resources. However, existingsystems for analyzing machine-generated data are incapable of providinginsights that benefit from metrics data, which is processedindependently by separate systems. As such, analyzing metrics dataand/or machine-generated data of computing resources is often difficult,thereby creating a significant cognitive burden on analysts to determinemeaningful insights about systems.

BRIEF DESCRIPTION OF THE DRAWINGS

One or more embodiments of the present disclosure are illustrated by wayof example and not limitation in the figures of the accompanyingdrawings, in which like references indicate similar elements.

FIG. 1 is a high-level system diagram in which an embodiment may beimplemented;

FIG. 2 is a block diagram illustrating a series of events including rawdata according to some embodiments of the present disclosure;

FIG. 3 illustrates a networked computer environment in which anembodiment may be implemented;

FIG. 4 illustrates a block diagram of an example data intake and querysystem in which an embodiment may be implemented;

FIG. 5 is a flow diagram illustrating how indexers process, index, andstore data received from forwarders according to some embodiments of thepresent disclosure;

FIG. 6 is a flow diagram illustrating how a search head and indexersperform a search query according to some embodiments of the presentdisclosure;

FIG. 7 illustrates a scenario where a common customer ID is found amonglog data received from three disparate sources according to someembodiments of the present disclosure;

FIG. 8A illustrates a search screen according to some embodiments of thepresent disclosure;

FIG. 8B illustrates a data summary dialog that enables a user to selectvarious data sources according to some embodiments of the presentdisclosure;

FIG. 9A illustrates a user interface screen for an example datamodel-driven report generation interface according to some embodimentsof the present disclosure;

FIG. 9B illustrates a user interface screen for an example datamodel-driven report generation interface according to some embodimentsof the present disclosure;

FIG. 9C illustrates a user interface screen for an example datamodel-driven report generation interface according to some embodimentsof the present disclosure;

FIG. 9D illustrates a user interface screen for an example datamodel-driven report generation interface according to some embodimentsof the present disclosure;

FIG. 10 illustrates an example search query received from a client andexecuted by search peers according to some embodiments of the presentdisclosure;

FIG. 11A illustrates a key indicators view according to some embodimentsof the present disclosure;

FIG. 11B illustrates an incident review dashboard according to someembodiments of the present disclosure;

FIG. 11C illustrates a proactive monitoring tree according to someembodiments of the present disclosure;

FIG. 11D illustrates a user interface screen displaying both log dataand performance data according to some embodiments of the presentdisclosure;

FIG. 12 illustrates a block diagram of an example cloud-based dataintake and query system in which an embodiment may be implemented;

FIG. 13 illustrates a block diagram of an example data intake and querysystem that performs searches across external data systems according tosome embodiments of the present disclosure;

FIG. 14 illustrates a user interface screen for an example datamodel-driven report generation interface according to some embodimentsof the present disclosure;

FIG. 15 illustrates a user interface screen for an example datamodel-driven report generation interface according to some embodimentsof the present disclosure;

FIG. 16 illustrates a user interface screen for an example datamodel-driven report generation interface according to some embodimentsof the present disclosure;

FIG. 17 illustrates example visualizations generated by a reportingapplication according to some embodiments of the present disclosure;

FIG. 18 illustrates example visualizations generated by a reportingapplication according to some embodiments of the present disclosure;

FIG. 19 illustrates example visualizations generated by a reportingapplication according to some embodiments of the present disclosure;

FIG. 20 is a block diagram of a system that can support storing andanalyzing metrics data according to some embodiments of the presentdisclosure;

FIG. 21 is a block diagram illustrating different types of collectionmechanisms that can transfer metrics or non-metrics data to a receiverof a data intake and query system according to some embodiments of thepresent disclosure;

FIG. 22 illustrates an example of a metric index including ingestedmetrics according to some embodiments of the present disclosure;

FIG. 23 is a flow diagram illustrating a method for ingesting metricsdata according to some embodiments of the present disclosure;

FIG. 24 is a flow diagram illustrating a method for creating metricsdata from ingested events according to some embodiments of the presentdisclosure;

FIG. 25 is a flow diagram illustrating a method for hash bucketingaccording to some embodiments of the present disclosure;

FIG. 26 is a block diagram illustrating a metrics cataloging system usedto search and monitor metrics data according to some embodiments of thepresent disclosure;

FIG. 27 is a flow diagram illustrating a method for using a catalog ofmetrics data according to some embodiments of the present disclosure;

FIG. 28 is a flow diagram illustrating a method for in memory catalogingof data related to metrics in a metrics store according to someembodiments of the present disclosure;

FIG. 29 illustrates a user interface screen of a metric catalogdisplaying a list of selectable metrics sources according to someembodiments of the present disclosure;

FIG. 30 illustrates a user interface screen of a metric catalogdisplaying a selected metric sources according to some embodiments ofthe present disclosure;

FIG. 31 illustrates a user interface screen of a metric catalogdisplaying filtering and/or searching of metrics according to someembodiments of the present disclosure;

FIG. 32 illustrates a user interface screen of a data ingestioninterface according to some embodiments of the present disclosure;

FIG. 33 illustrates a user interface screen for searching and selectingvarious types of data including metrics according to some embodiments ofthe present disclosure;

FIG. 34 is a flow diagram illustrating a method for investigating ofmetrics data according to some embodiments of the present disclosure;

FIG. 35 illustrates a user interface screen of a metric investigationinterface for visualizing selected metrics data according to someembodiments of the present disclosure;

FIG. 36 illustrates a user interface screen of a metric investigationinterface for customizing a visualization of metrics according to someembodiments of the present disclosure;

FIG. 37 illustrates a user interface screen of a metric investigationinterface including a visualization of metrics from multiple sourcesaccording to some embodiments of the present disclosure;

FIG. 38 illustrates a user interface screen of a metric investigationinterface according to some embodiments of the present disclosure;

FIG. 39 illustrates a user interface screen of a metric investigationinterface according to some embodiments of the present disclosure;

FIG. 40 illustrates a user interface screen of a metric investigationinterface including query auto-completion according to some embodimentsof the present disclosure;

FIG. 41 illustrates a user interface screen of a metric investigationinterface including visualizations of metrics data according to someembodiments of the present disclosure;

FIG. 42 illustrates a user interface screen of a metric investigationinterface including searchable visualizations of metrics data accordingto some embodiments of the present disclosure;

FIG. 43 illustrates a user interface screen of a metric investigationinterface including various visualizations of metrics data according tosome embodiments of the present disclosure;

FIG. 44 illustrates a user interface screen of a metric investigationinterface including metrics summaries according to some embodiments ofthe present disclosure;

FIG. 45 illustrates a user interface screen of a metric investigationinterface including outlier detection according to some embodiments ofthe present disclosure;

FIG. 46 illustrates a user interface screen of a metric investigationinterface including query auto-completion according to some embodimentsof the present disclosure;

FIG. 47 illustrates a user interface screen of a metric investigationinterface including visualizations of related metrics according to someembodiments of the present disclosure;

FIG. 48 illustrates a user interface screen of a metric investigationinterface a visualizations of a search according to some embodiments ofthe present disclosure;

FIG. 49 illustrates a user interface screen of a metric investigationinterface including dimensions of metrics data that can be split forvisualizations according to some embodiments of the present disclosure;

FIG. 50 illustrates a user interface screen of a metric investigationinterface including a mechanism to add a workspace on an existing chartaccording to some embodiments of the present disclosure;

FIG. 51 illustrates a user interface screen of a metric investigationinterface including separate visualizations of metrics data fromdifferent sources according to some embodiments of the presentdisclosure;

FIG. 52 illustrates a user interface screen of a metric investigationinterface including query auto-completion according to some embodimentsof the present disclosure;

FIG. 53 illustrates a user interface screen of a metric investigationinterface including an interface for customizing visualizationsaccording to some embodiments of the present disclosure;

FIG. 54 illustrates a user interface screen of a metric investigationinterface including various dimensions of overlaid visualizationsaccording to some embodiments of the present disclosure;

FIG. 55 illustrates a user interface screen of a metric investigationinterface including a list of events selected from a visualizationaccording to some embodiments of the present disclosure;

FIG. 56 illustrates a user interface screen of a metric investigationinterface including an overlaid pop-up screen for saving an analysis toa dashboard according to some embodiments of the present disclosure; and

FIG. 57 is a flow diagram illustrating a method for performing real-timesearches according to some embodiments of the present disclosure;

FIG. 58 is a block diagram illustrating examples of a msidx file,optional companion journal, and an acceleration table, used to processqueries for metrics data according to some embodiments of the presentdisclosure;

FIG. 59 is a flow diagram illustrating a method for performing metricsqueries according to some embodiments of the present disclosure; and

FIG. 60 is a block diagram illustrating a high-level example of ahardware architecture of a computing system in which an embodiment maybe implemented.

DETAILED DESCRIPTION

The ensuing description provides exemplary embodiments only and is notintended to limit the scope, applicability, or configuration of thedisclosure. Rather, the ensuing description of the exemplary embodimentswill provide those skilled in the art with an enabling description forimplementing a preferred exemplary embodiment. It is understood thatvarious changes can be made in the function and arrangement of elementswithout departing from the spirit and scope as set forth in the appendedclaims.

In this description, references to “an embodiment,” “one embodiment,” orthe like mean that the particular feature, function, structure orcharacteristic being described is included in at least one embodiment ofthe technique introduced herein. Occurrences of such phrases in thisspecification do not necessarily all refer to the same embodiment. Onthe other hand, the embodiments referred to are also not necessarilymutually exclusive.

A data intake and query system can index and store data in data storesof indexers and can process search queries causing a search of theindexers to obtain search results. The data indexed and stored by thedata intake and query system typically includes non-metrics data, suchas raw machine-generated data (e.g., application logs). The raw data mayinclude metrics data. In some cases, the data intake and query systemcan receive structured metrics data including, for example, a timeseries of metrics generated for a computing resource.

The metrics data and non-metrics data provide insights into theoperations and performance of computing resources. In some cases, theinsights obtained by analyzing metrics data may complement the insightsobtained by analyzing non-metrics data. Moreover, the diverse nature ofthe metrics and non-metrics data can further enrich an analysis ofcomputing resources to obtain useful insights into the operations andperformance of computing resources. However, analyzing metrics andnon-metrics data is often complex and requires using different technicaltools, thereby creating a significant cognitive burden on analysts.

The disclosed embodiments overcome these drawbacks with a data intakeand query system that can process metrics and non-metrics data to obtainuseful and meaningful insights into the operations and performance ofcomputing resources. The disclosed embodiments also include techniquesthat improve intake, storage, and querying of metrics data alone,separate from non-metrics data. As such, the disclosed embodimentsreduce the cognitive burden on analysts to obtain useful insights of acomputing system based on metrics data alone, or in combination withnon-metrics data.

FIG. 1 is a high-level system diagram in which an embodiment may beimplemented. The system 10 includes data intake and query system 12interconnected to various components over a network 14. The componentsinclude a source 16 of metrics data, another source 18 of non-metricsdata, and another source 20 of both metrics and non-metrics data. Thesources 16, 18, and/or 20 (“the sources”) include computing resourcesthat can generate data (e.g., log data) or are the basis from which datacan be generated (e.g., measured performance). The data from thesesources can be transferred to the data intake and query system 12 overthe network 14.

The metrics data may include unstructured raw data, semi-structureddata, or structured data. “Structured data” may refer to informationwith a high degree of organization, such that inclusion in a relationaldatabase is seamless and readily searchable by simple, straightforwardsearch engine algorithms or other search operations. “Semi-structureddata” may refer to a form of structured data that does not conform withthe formal structure of data models typically associated with relationaldatabases or other forms of data tables, but nonetheless contains tagsor other markers to separate semantic elements and enforce hierarchiesof records and fields within the data. Lastly, “unstructured data” mayrefer to information that either does not have a pre-defined data modelor is not organized in a pre-defined manner.

The non-metrics data may include raw machine data. The system 10 canalso include a client device 22 running one or more client applications24. The client device 22 may access the data intake and query system 12or any other components of the system 10. For example, the client devicemay include a user interface (UI) rendered on a display device thatprovides an interactive platform to access and control components of thesystem 10 over the network 14.

The volume of data generated or collected of the sources can grow atvery high rates as the number of transactions and diverse computingresources grows. A portion of this large volume of data could beprocessed and stored by the data intake and query system 12 while otherportions could be stored in any of the sources. In an effort to reducethe vast amounts of data generated in this data ecosystem, some systems(e.g., the sources) may pre-process the raw data based on anticipateddata analysis needs, store the pre-processed data, and discard anyremaining raw data. However, discarding massive amounts of raw data canresult in the loss of valuable insights that could have been obtained bysearching all of the raw data.

In contrast, the data intake and query system 12 can address some ofthese challenges by collecting and storing raw data as structured“events.” FIG. 2 is a block diagram illustrating a series of events,including raw data, according to some embodiments of the presentdisclosure. An event includes a portion of raw data and is associatedwith a specific point in time. For example, events may be derived from“time series data,” where the time series data comprises a sequence ofdata points (e.g., performance measurements from a computer system) thatare associated with successive points in time.

As shown, each event 1 through K can be associated with a timestamp 1through K that can be derived from the raw data in the respective event,determined through interpolation between temporally proximate eventshaving known timestamps, or determined based on other configurable rulesfor associating timestamps with events. During operation of the dataintake and query system 12, ingested raw data is divided into segmentsof raw data delineated by time segments (e.g., blocks of raw data, eachassociated with a specific time frame). The segments of raw data areindexed as timestamped events, corresponding to their respective timesegments as shown in FIG. 2. The system stores the timestamped events ina data store.

In some instances, data systems can store raw data in a predefinedformat, where data items with specific data formats are stored atpredefined locations in the data. For example, the raw data may includedata stored as fields. In other instances, raw data may not have apredefined format; that is, the data is not at fixed, predefinedlocations, but the data does have repeatable patterns and is not random.This means that some raw data can comprise various data items ofdifferent data types that may be stored at different locations withinthe raw data. As shown in FIG. 2, each event 1 through K includes afield that is nine characters in length beginning after a semicolon on afirst line of the raw data, for example. In certain embodiments, thesefields can be queried to extract their contents.

In some embodiments, systems can store raw data as events that areindexed by timestamps but are also associated with predetermined dataitems. This structure is essentially a modification of database systemsthat require predetermining data items for subsequent searches. Thesesystems can be modified to retain the remaining raw data for subsequentre-processing for other predetermined data items.

Specifically, the raw data can be divided into segments and indexed bytimestamps. The predetermined data items can be associated with theevents indexed by timestamps. The events can be searched only for thepredetermined data items during search time; the events can bere-processed later in time to re-index the raw data, and generate eventswith new predetermined data items. As such, the data systems of thesystem 10 can store related data in a variety of pre-processed data andraw data in a variety of structures.

In some cases, the sources can generate, process, and/or storesemi-structured or structured metrics data. The metrics data includes atleast one metric, which includes at least one or only one numericalvalue that represents a performance measurement of a characteristic of acomputing resource. The data intake and query system can obtain themetrics data from the sources over the network 14 via a variety ofmechanism, which are described in greater detail below. However,existing data intake and query systems that can handle metrics data andnon-metrics data underperform systems that only handle one type of data.This is caused, in part, because metrics data is uniquely different fromother types of data. Additionally, the processes for handling non-metricdata can be incompatible with processes for handing metrics data.

For example, each metric includes at least one or possibly only onenumerical value that represents the metric's measure. Each numericalvalue can be a highly precise floating point number. Hence, thecardinality of metrics data is exceedingly large compared to other typesof data. That is, each metric tends to have a uniquely different measurecompared to other metrics, except for the possible repeating value ofzero. As such, existing systems that are designed to efficiently handlenon-metrics data cannot efficiently handle metrics data the same way,which causes the overall processing of metrics to be less efficientcompared to systems that process only metrics data. However, usingindependent systems to process and analyze metrics and non-metrics datafails to exploit relationships between these types of data to obtainnew, useful, and meaning insights into the operations and performance ofsystems.

A number of tools are available to separately process, store, search,and analyze metrics data and non-metrics data from diverse systems. Assuch, an analyst can use a first tool to process metrics data from thesource 16 and a second tool to process the non-metrics data from thesource 18. The analyst then has the choice of using different tools toprocess the metrics data and non-metrics data separately and to manuallyderive correlations between the metrics and non-metrics data, or to usea single underperforming tool to process both metrics data andnon-metrics data; however, the analyst is still required to manuallyderive correlations between the metrics and non-metrics types of data.Thus, existing tools cannot obtain valuable insights from diverse typesof metric data alone, or combinations of diverse types of metrics dataand non-metrics data. Examples of these valuable insights may includecorrelations between metrics data and non-metrics data. The disclosedembodiments overcome at least these drawbacks.

1.0. GENERAL OVERVIEW

Modern data centers and other computing environments can compriseanywhere from a few host computer systems to thousands of systemsconfigured to process data, service requests from remote clients, andperform numerous other computational tasks. During operation, variouscomponents within these computing environments often generatesignificant volumes of machine-generated data. For example, machine datais generated by various components in the information technology (IT)environments, such as servers, sensors, routers, mobile devices,Internet of Things (IoT) devices, etc. Machine-generated data caninclude system logs, network packet data, sensor data, applicationprogram data, error logs, stack traces, system performance data, etc. Ingeneral, machine-generated data can also include performance data,diagnostic information, and many other types of data that can beanalyzed to diagnose performance problems, monitor user interactions,and to derive other insights.

A number of tools are available to analyze machine data, that is,machine-generated data. In order to reduce the size of the potentiallyvast amount of machine data that may be generated, many of these toolstypically pre-process the data based on anticipated data-analysis needs.For example, pre-specified data items may be extracted from the machinedata and stored in a database to facilitate efficient retrieval andanalysis of those data items at search time. However, the rest of themachine data typically is not saved and discarded during pre-processing.As storage capacity becomes progressively cheaper and more plentiful,there are fewer incentives to discard these portions of machine data andmany reasons to retain more of the data.

This plentiful storage capacity is presently making it feasible to storemassive quantities of minimally processed machine data for laterretrieval and analysis. In general, storing minimally processed machinedata and performing analysis operations at search time can providegreater flexibility because it enables an analyst to search all of themachine data, instead of searching only a pre-specified set of dataitems. This may enable an analyst to investigate different aspects ofthe machine data that previously were unavailable for analysis.

However, analyzing and searching massive quantities of machine datapresents a number of challenges. For example, a data center, servers, ornetwork appliances may generate many different types and formats ofmachine data (e.g., system logs, network packet data (e.g., wire data,etc.), sensor data, application program data, error logs, stack traces,system performance data, operating system data, virtualization data,etc.) from thousands of different components, which can collectively bevery time-consuming to analyze. In another example, mobile devices maygenerate large amounts of information relating to data accesses,application performance, operating system performance, networkperformance, etc. There can be millions of mobile devices that reportthese types of information.

These challenges can be addressed by using an event-based data intakeand query system, such as the SPLUNK® ENTERPRISE system developed bySplunk Inc. of San Francisco, Calif. The SPLUNK® ENTERPRISE system isthe leading platform for providing real-time operational intelligencethat enables organizations to collect, index, and searchmachine-generated data from various websites, applications, servers,networks, and mobile devices that power their businesses. The SPLUNK®ENTERPRISE system is particularly useful for analyzing data which iscommonly found in system log files, network data, and other data inputsources. Although many of the techniques described herein are explainedwith reference to a data intake and query system similar to the SPLUNK®ENTERPRISE system, these techniques are also applicable to other typesof data systems.

In the SPLUNK® ENTERPRISE system, machine-generated data are collectedand stored as “events”. An event comprises a portion of themachine-generated data and is associated with a specific point in time.For example, events may be derived from “time series data,” where thetime series data comprises a sequence of data points (e.g., performancemeasurements from a computer system, etc.) that are associated withsuccessive points in time. In general, each event can be associated witha timestamp that is derived from the raw data in the event, determinedthrough interpolation between temporally proximate events having knowntimestamps, or determined based on other configurable rules forassociating timestamps with events, etc.

In some instances, machine data can have a predefined format, where dataitems with specific data formats are stored at predefined locations inthe data. For example, the machine data may include data stored asfields in a database table. In other instances, machine data may nothave a predefined format, that is, the data is not at fixed, predefinedlocations, but the data does have repeatable patterns and is not random.This means that some machine data can comprise various data items ofdifferent data types and that may be stored at different locationswithin the data. For example, when the data source is an operatingsystem log, an event can include one or more lines from the operatingsystem log containing raw data that includes different types ofperformance and diagnostic information associated with a specific pointin time.

Examples of components which may generate machine data from which eventscan be derived include, but are not limited to, web servers, applicationservers, databases, firewalls, routers, operating systems, and softwareapplications that execute on computer systems, mobile devices, sensors,Internet of Things (IoT) devices, etc. The data generated by such datasources can include, for example and without limitation, server logfiles, activity log files, configuration files, messages, network packetdata, performance measurements, sensor measurements, etc.

The SPLUNK® ENTERPRISE system uses flexible schema to specify how toextract information from the event data. A flexible schema may bedeveloped and redefined as needed. Note that a flexible schema may beapplied to event data “on the fly,” when it is needed (e.g., at searchtime, index time, ingestion time, etc.). When the schema is not appliedto event data until search time, it may be referred to as a“late-binding schema.”

During operation, the SPLUNK® ENTERPRISE system starts with raw inputdata (e.g., one or more system logs, streams of network packet data,sensor data, application program data, error logs, stack traces, systemperformance data, etc.). The system divides this raw data into blocks(e.g., buckets of data, each associated with a specific time frame,etc.) and parses the raw data to produce timestamped events. The systemstores the timestamped events in a data store. The system enables usersto run queries against the stored data to, for example, retrieve eventsthat meet criteria specified in a query, such as containing certainkeywords or having specific values in defined fields. As used hereinthroughout, data that is part of an event is referred to as “eventdata”. In this context, the term “field” refers to a location in theevent data containing one or more values for a specific data item. Aswill be described in more detail herein, the fields are defined byextraction rules (e.g., regular expressions) that derive one or morevalues from the portion of raw machine data in each event that has aparticular field specified by an extraction rule. The set of valuesproduced are semantically-related (such as IP address), even though theraw machine data in each event may be in different formats (e.g.,semantically-related values may be in different positions in the eventsderived from different sources).

As noted above, the SPLUNK® ENTERPRISE system utilizes a late-bindingschema to event data while performing queries on events. One aspect of alate-binding schema is applying “extraction rules” to event data toextract values for specific fields during search time. Morespecifically, the extraction rules for a field can include one or moreinstructions that specify how to extract a value for the field from theevent data. An extraction rule can generally include any type ofinstruction for extracting values from data in events. In some cases, anextraction rule comprises a regular expression where a sequence ofcharacters forms a search pattern, in which case the rule is referred toas a “regex rule.” The system applies the regex rule to the event datato extract values for associated fields in the event data by searchingthe event data for the sequence of characters defined in the regex rule.

In the SPLUNK® ENTERPRISE system, a field extractor may be configured toautomatically generate extraction rules for certain field values or fora group of common field values (e.g., CPU metric from different sourcesAmazon Web Services, Google Cloud Platform, Linux OS) in the events,when the events are being created, indexed, or stored, or possibly at alater time. Alternatively, a user may manually define extraction rulesfor fields or a group of fields using a variety of techniques. Incontrast to a conventional schema for a database system, a late-bindingschema is not defined at data ingestion time. Instead, the late-bindingschema can be developed on an ongoing basis until the time a query isactually executed. This means that extraction rules for the fields in aquery may be provided in the query itself, or may be located duringexecution of the query. Hence, as a user learns more about the data inthe events, the user can continue to refine the late-binding schema byadding new fields, deleting fields, or modifying the field extractionrules for use the next time the schema is used by the system. Becausethe SPLUNK® ENTERPRISE system maintains the underlying raw data and useslate-binding schema for searching the raw data, it enables a user tocontinue investigating and learning valuable insights about the rawdata.

In some embodiments, a common field name may be used to reference two ormore fields containing equivalent data items, even though the fields maybe associated with different types of events that possibly havedifferent data formats and different extraction rules. By enabling acommon field name to be used to identify equivalent fields fromdifferent types of events generated by disparate data sources, thesystem facilitates use of a “common information model” (CIM) across thedisparate data sources (further discussed with respect to FIG. 7).

2.0. OPERATING ENVIRONMENT

FIG. 3 illustrates a networked computer system 26 in which an embodimentmay be implemented. Those skilled in the art would understand that FIG.3 represents one example of a networked computer system and otherembodiments may use different arrangements.

The networked computer system 26 comprises one or more computingdevices. These one or more computing devices comprise any combination ofhardware and software configured to implement the various logicalcomponents described herein. For example, the one or more computingdevices may include one or more memories that store instructions forimplementing the various components described herein, one or morehardware processors configured to execute the instructions stored in theone or more memories, and various data repositories in the one or morememories for storing data structures utilized and manipulated by thevarious components.

In an embodiment, one or more client devices 28 are coupled to one ormore host devices 30 and a data intake and query system 32 (alsoreferred to as “system 32”) via one or more networks 34. In someembodiments, the data intake and query system 32 is similar or the sameas the data intake and query system 12 of FIG. 1. Networks 34 broadlyrepresent one or more LANs, WANs, cellular networks (e.g., LTE, HSPA,3G, and other cellular technologies), and/or networks using any ofwired, wireless, terrestrial microwave, or satellite links, and mayinclude the public Internet.

2.1. Host Devices

In the illustrated embodiment, a system 26 includes one or more hostdevices 30. Host devices 30 may broadly include any number of computers,virtual machine instances, and/or data centers that are configured tohost or execute one or more instances of host applications 36. Ingeneral, a host device 30 may be involved, directly or indirectly, inprocessing requests received from client devices 28. Each host device 30may comprise, for example, one or more of a network device, a webserver, an application server, a database server, etc. A collection ofhost devices 30 may be configured to implement a network-based service.For example, a provider of a network-based service may configure one ormore host devices 30 and host applications 36 (e.g., one or more webservers, application servers, database servers, etc.) to collectivelyimplement the network-based application.

In general, client devices 28 communicate with one or more hostapplications 36 to exchange information. The communication between aclient device 28 and a host application 36 may, for example, be based onthe Hypertext Transfer Protocol (HTTP) or any other network protocol.Content delivered from the host application 36 to a client device 28 mayinclude, for example, HTML documents, media content, etc. Thecommunication between a client device 28 and host application 36 mayinclude sending various requests and receiving data packets. Forexample, in general, a client device 28 or application running on aclient device may initiate communication with a host application 38 bymaking a request for a specific resource (e.g., based on an HTTPrequest), and the application server may respond with the requestedcontent stored in one or more response packets.

In the illustrated embodiment, one or more of host applications 38 maygenerate various types of performance data during operation, includingevent logs, network data, sensor data, and other types ofmachine-generated data. For example, a host application 38 comprising aweb server may generate one or more web server logs in which details ofinteractions between the web server and any number of client devices 28is recorded. As another example, a host device 30 comprising a routermay generate one or more router logs that record information related tonetwork traffic managed by the router. As yet another example, a hostapplication 38 comprising a database server may generate one or morelogs that record information related to requests sent from other hostapplications 38 (e.g., web servers or application servers) for datamanaged by the database server.

2.2. Client Devices

Client devices 28 of FIG. 3 represent any computing device capable ofinteracting with one or more host devices 30 via a network (connected orwireless) 34. Examples of client devices 28 may include, withoutlimitation, smart phones, tablet computers, handheld computers, wearabledevices, laptop computers, desktop computers, servers, portable mediaplayers, gaming devices, and so forth. In general, a client device 28can provide access to different content, for instance, content providedby one or more host devices 30, etc. Each client device 28 may compriseone or more client applications 38, described in more detail in aseparate section hereinafter.

2.3. Client Device Applications

In an embodiment, each client device 28 may host or execute one or moreclient applications 38 that are capable of interacting with one or morehost devices 30 via one or more networks 34. For instance, a clientapplication 38 may be or comprise a web browser that a user may use tonavigate to one or more websites or other resources provided by one ormore host devices 30. As another example, a client application 38 maycomprise a mobile application or “app.” For example, an operator of anetwork-based service hosted by one or more host devices 30 may makeavailable one or more mobile apps that enable users of client devices 28to access various resources of the network-based service. As yet anotherexample, client applications 38 may include background processes thatperform various operations without direct interaction from a user. Aclient application 38 may include a “plug-in” or “extension” to anotherapplication, such as a web browser plug-in or extension.

In an embodiment, a client application 38 may include a monitoringcomponent 40. At a high level, the monitoring component 40 comprises asoftware component or other logic that facilitates generatingperformance data related to a client device's operating state, includingmonitoring network traffic sent and received from the client device andcollecting other device and/or application-specific information.Monitoring component 40 may be an integrated component of a clientapplication 38, a plug-in, an extension, or any other type of add-oncomponent. Monitoring component 40 may also be a stand-alone process.

In one embodiment, a monitoring component 40 may be created when aclient application 38 is developed, for example, by an applicationdeveloper using a software development kit (SDK). The SDK may includecustom monitoring code that can be incorporated into the codeimplementing a client application 38. When the code is converted to anexecutable application, the custom code implementing the monitoringfunctionality can become part of the application itself.

In some cases, an SDK or other code for implementing the monitoringfunctionality may be offered by a provider of a data intake and querysystem, such as a system 32. In such cases, the provider of the system32 can implement the custom code so that performance data generated bythe monitoring functionality is sent to the system 32 to facilitateanalysis of the performance data by a developer of the clientapplication or other users.

In an embodiment, the custom monitoring code may be incorporated intothe code of a client application 38 in a number of different ways, suchas the insertion of one or more lines in the client application codethat call or otherwise invoke the monitoring component 40. As such, adeveloper of a client application 38 can add one or more lines of codeinto the client application 38 to trigger the monitoring component 40 atdesired points during execution of the application. Code that triggersthe monitoring component may be referred to as a monitor trigger. Forinstance, a monitor trigger may be included at or near the beginning ofthe executable code of the client application 38 such that themonitoring component 40 is initiated or triggered as the application islaunched, or included at other points in the code that correspond tovarious actions of the client application, such as sending a networkrequest or displaying a particular interface.

In an embodiment, the monitoring component 40 may monitor one or moreaspects of network traffic sent and/or received by a client application38. For example, the monitoring component 40 may be configured tomonitor data packets transmitted to and/or from one or more hostapplications 36. Incoming and/or outgoing data packets can be read orexamined to identify network data contained within the packets, forexample, and other aspects of data packets can be analyzed to determinea number of network performance statistics. Monitoring network trafficmay enable information to be gathered particular to the networkperformance associated with a client application 38 or set ofapplications.

In an embodiment, network performance data refers to any type of datathat indicates information about the network and/or network performance.Network performance data may include, for instance, a URL requested, aconnection type (e.g., HTTP, HTTPS, etc.), a connection start time, aconnection end time, an HTTP status code, request length, responselength, request headers, response headers, connection status (e.g.,completion, response time(s), failure, etc.), and the like. Uponobtaining network performance data indicating performance of thenetwork, the network performance data can be transmitted to a dataintake and query system 32 for analysis.

Upon developing a client application 38 that incorporates a monitoringcomponent 40, the client application 38 can be distributed to clientdevices 28. Applications generally can be distributed to client devices28 in any manner, or they can be pre-loaded. In some cases, theapplication may be distributed to a client device 28 via an applicationmarketplace or other application distribution system. For instance, anapplication marketplace or other application distribution system mightdistribute the application to a client device based on a request fromthe client device to download the application.

Examples of functionality that enable monitoring performance of a clientdevice are described in U.S. patent application Ser. No. 14/524,748,entitled “UTILIZING PACKET HEADERS TO MONITOR NETWORK TRAFFIC INASSOCIATION WITH A CLIENT DEVICE”, filed on 27 Oct. 2014, and which ishereby incorporated by reference in its entirety for all purposes.

In an embodiment, the monitoring component 40 may also monitor andcollect performance data related to one or more aspects of theoperational state of a client application 38 and/or client device 28.For example, a monitoring component 40 may be configured to collectdevice performance information by monitoring one or more client deviceoperations, or by making calls to an operating system and/or one or moreother applications executing on a client device 28 for performanceinformation. Device performance information may include, for instance, acurrent wireless signal strength of the device, a current connectiontype and network carrier, current memory performance information, ageographic location of the device, a device orientation, and any otherinformation related to the operational state of the client device.

In an embodiment, the monitoring component 40 may also monitor andcollect other device profile information including, for example, a typeof client device, a manufacturer and model of the device, versions ofvarious software applications installed on the device, and so forth.

In general, a monitoring component 40 may be configured to generateperformance data in response to a monitor trigger in the code of aclient application 38 or other triggering application event, asdescribed above, and to store the performance data in one or more datarecords. Each data record, for example, may include a collection offield-value pairs, each field-value pair storing a particular item ofperformance data in association with a field for the item. For example,a data record generated by a monitoring component 40 may include a“networkLatency” field (not shown in the Figure) in which a value isstored. This field indicates a network latency measurement associatedwith one or more network requests. The data record may include a “state”field to store a value indicating a state of a network connection, andso forth for any number of aspects of collected performance data.

2.4. Data Server System

FIG. 4 depicts a block diagram of an exemplary data intake and querysystem 32, similar to the SPLUNK® ENTERPRISE system. System 32 includesone or more forwarders 42 that receive data from a variety of input datasources 44, and one or more indexers 46 that process and store the datain one or more data stores 48. These forwarders and indexers cancomprise separate computer systems, or may alternatively compriseseparate processes executing on one or more computer systems.

Each data source 44 broadly represents a distinct source of data thatcan be consumed by a system 32. Examples of a data source 44 include,without limitation, data files, directories of files, data sent over anetwork, event logs, registries, etc.

During operation, the forwarders 42 identify which indexers 46 receivedata collected from a data source 44 and forward the data to theappropriate indexers. Forwarders 42 can also perform operations on thedata before forwarding, including removing extraneous data, detectingtimestamps in the data, parsing data, indexing data, routing data basedon criteria relating to the data being routed, and/or performing otherdata transformations.

In an embodiment, a forwarder 42 may comprise a service accessible toclient devices 28 and host devices 30 via a network 34. For example, onetype of forwarder 42 may be capable of consuming vast amounts ofreal-time data from a potentially large number of client devices 28and/or host devices 30. The forwarder 42 may, for example, comprise acomputing device which implements multiple data pipelines or “queues” tohandle forwarding of network data to indexers 46. A forwarder 42 mayalso perform many of the functions that are performed by an indexer. Forexample, a forwarder 42 may perform keyword extractions on raw data orparse raw data to create events. A forwarder 42 may generate time stampsfor events. Additionally or alternatively, a forwarder 42 may performrouting of events to indexers. Data store 48 may contain events derivedfrom machine data from a variety of sources all pertaining to the samecomponent in an IT environment, and this data may be produced by themachine in question or by other components in the IT environment.

2.5. Data Ingestion

FIG. 5 depicts a flow chart illustrating an example data flow performedby data intake and query system 32, in accordance with the disclosedembodiments. The data flow illustrated in FIG. 5 is provided forillustrative purposes only; those skilled in the art would understandthat one or more of the steps of the processes illustrated in FIG. 5 maybe removed or the ordering of the steps may be changed. Furthermore, forthe purposes of illustrating a clear example, one or more particularsystem components are described in the context of performing variousoperations during each of the data flow stages. For example, a forwarderis described as receiving and processing data during an input phase; anindexer is described as parsing and indexing data during parsing andindexing phases; and a search head is described as performing a searchquery during a search phase. However, other system arrangements anddistributions of the processing steps across system components may beused.

2.5.1. Input

At step 502, a forwarder receives data from an input source, such as adata source 44 shown in FIG. 2. A forwarder initially may receive thedata as a raw data stream generated by the input source. For example, aforwarder may receive a data stream from a log file generated by anapplication server, from a stream of network data from a network device,or from any other source of data. In one embodiment, a forwarderreceives the raw data and may segment the data stream into “blocks”, or“buckets,” possibly of a uniform data size, to facilitate subsequentprocessing steps.

At step 504, a forwarder or other system component annotates each blockgenerated from the raw data with one or more metadata fields. Thesemetadata fields may, for example, provide information related to thedata block as a whole and may apply to each event that is subsequentlyderived from the data in the data block. For example, the metadatafields may include separate fields specifying each of a host, a source,and a source type related to the data block. A host field may contain avalue identifying a host name or IP address of a device that generatedthe data. A source field may contain a value identifying a source of thedata, such as a pathname of a file or a protocol and port related toreceived network data. A source type field may contain a valuespecifying a particular source type label for the data. Additionalmetadata fields may also be included during the input phase, such as acharacter encoding of the data, if known, and possibly other values thatprovide information relevant to later processing steps. In anembodiment, a forwarder forwards the annotated data blocks to anothersystem component (typically an indexer) for further processing.

The SPLUNK® ENTERPRISE system allows forwarding of data from one SPLUNK®ENTERPRISE instance to another, or even to a third-party system. SPLUNK®ENTERPRISE system can employ different types of forwarders in aconfiguration.

In an embodiment, a forwarder may contain the essential componentsneeded to forward data. It can gather data from a variety of inputs andforward the data to a SPLUNK® ENTERPRISE server for indexing andsearching. It also can tag metadata (e.g., source, source type, host,etc.).

Additionally or optionally, in an embodiment, a forwarder has thecapabilities of the aforementioned forwarder as well as additionalcapabilities. The forwarder can parse data before forwarding the data(e.g., associate a time stamp with a portion of data and create anevent, etc.) and can route data based on criteria such as source or typeof event. It can also index data locally while forwarding the data toanother indexer.

2.5.2. Parsing

At step 506, an indexer receives data blocks from a forwarder and parsesthe data to organize the data into events. In an embodiment, to organizethe data into events, an indexer may determine a source type associatedwith each data block (e.g., by extracting a source type label from themetadata fields associated with the data block, etc.) and refer to asource type configuration corresponding to the identified source type.The source type definition may include one or more properties thatindicate to the indexer to automatically determine the boundaries ofevents within the data. In general, these properties may include regularexpression-based rules or delimiter rules where, for example, eventboundaries may be indicated by predefined characters or characterstrings. These predefined characters may include punctuation marks orother special characters including, for example, carriage returns, tabs,spaces, line breaks, etc. If a source type for the data is unknown tothe indexer, an indexer may infer a source type for the data byexamining the structure of the data. Then, it can apply an inferredsource type definition to the data to create the events.

At step 508, the indexer determines a timestamp for each event. Similarto the process for creating events, an indexer may again refer to asource type definition associated with the data to locate one or moreproperties that indicate instructions for determining a timestamp foreach event. The properties may, for example, instruct an indexer toextract a time value from a portion of data in the event, to interpolatetime values based on timestamps associated with temporally proximateevents, to create a timestamp based on a time the event data wasreceived or generated, to use the timestamp of a previous event, or touse any other rules for determining timestamps.

At step 510, the indexer associates with each event one or more metadatafields including a field containing the timestamp (in some embodiments,a timestamp may be included in the metadata fields) determined for theevent. These metadata fields may include a number of “default fields”that are associated with all events, and may also include one morecustom fields as defined by a user. Similar to the metadata fieldsassociated with the data blocks at step 504, the default metadata fieldsassociated with each event may include a host, source, and source typefield including or in addition to a field storing the timestamp.

At step 512, an indexer may optionally apply one or more transformationsto data included in the events created at step 506. For example, suchtransformations can include removing a portion of an event (e.g., aportion used to define event boundaries, extraneous characters from theevent, other extraneous text, etc.), masking a portion of an event(e.g., masking a credit card number), removing redundant portions of anevent, etc. The transformations applied to event data may, for example,be specified in one or more configuration files and referenced by one ormore source type definitions.

2.5.3. Indexing

At steps 514 and 516, an indexer can optionally generate a keyword indexto facilitate fast keyword searching for event data. To build a keywordindex, at step 514, the indexer identifies a set of keywords in eachevent. At step 516, the indexer includes the identified keywords in anindex, which associates each stored keyword with reference pointers toevents containing that keyword (or to locations within events where thatkeyword is located, other location identifiers, etc.). When an indexersubsequently receives a keyword-based query, the indexer can access thekeyword index to quickly identify events containing the keyword.

In some embodiments, the keyword index may include entries forname-value pairs found in events, where a name-value pair can include apair of keywords connected by a symbol, such as an equals sign or colon.This way, events containing these name-value pairs can be quicklylocated. In some embodiments, fields can automatically be generated forsome or all of the name-value pairs at the time of indexing. Forexample, if the string “dest=10.0.1.2” is found in an event, a fieldnamed “dest” may be created for the event, and assigned a value of“10.0.1.2”.

At step 518, the indexer stores the events with an associated timestampin a data store 48. Timestamps enable a user to search for events basedon a time range. In one embodiment, the stored events are organized into“buckets,” where each bucket stores events associated with a specifictime range based on the timestamps associated with each event. This maynot only improve time-based searching, but also allows for events withrecent timestamps, which may have a higher likelihood of being accessed,to be stored in a faster memory to facilitate faster retrieval. Forexample, buckets containing the most recent events can be stored inflash memory rather than on a hard disk.

Each indexer 46 may be responsible for storing and searching a subset ofthe events contained in a corresponding data store 48. By distributingevents among the indexers and data stores, the indexers can analyzeevents for a query in parallel. For example, using map-reducetechniques, each indexer returns partial responses for a subset ofevents to a search head that combines the results to produce an answerfor the query. By storing events in buckets for specific time ranges, anindexer may further optimize data retrieval process by searching bucketscorresponding to time ranges that are relevant to a query.

Moreover, events and buckets can also be replicated across differentindexers and data stores to facilitate high availability and disasterrecovery as described in U.S. patent application Ser. No. 14/266,812,entitled “SITE-BASED SEARCH AFFINITY”, filed on 30 Apr. 2014, and inU.S. patent application Ser. No. 14/266,817, entitled “MULTI-SITECLUSTERING”, also filed on 30 Apr. 2014, each of which is herebyincorporated by reference in its entirety for all purposes.

2.6. Query Processing

FIG. 6 is a flow diagram that illustrates an exemplary process that asearch head and one or more indexers may perform during a search query.At step 602, a search head receives a search query from a client. Atstep 604, the search head analyzes the search query to determine whatportion(s) of the query can be delegated to indexers and what portionsof the query can be executed locally by the search head. At step 606,the search head distributes the determined portions of the query to theappropriate indexers. In an embodiment, a search head cluster may takethe place of an independent search head where each search head in thesearch head cluster coordinates with peer search heads in the searchhead cluster to schedule jobs, replicate search results, updateconfigurations, fulfill search requests, etc. In an embodiment, thesearch head (or each search head) communicates with a master node (alsoknown as a cluster master, not shown in FIG.) that provides the searchhead with a list of indexers to which the search head can distribute thedetermined portions of the query. The master node maintains a list ofactive indexers and can also designate which indexers may haveresponsibility for responding to queries over certain sets of events. Asearch head may communicate with the master node before the search headdistributes queries to indexers to discover the addresses of activeindexers.

At step 608, the indexers to which the query was distributed search datastores associated with them for events and/or aspects of events (such asperformance metrics derived from the events, dimensions of theperformance metrics, logs, etc.) that are responsive to the query. Todetermine which events (or aspects of an event) are responsive to thequery, the indexer searches for machine data that match the criteriaspecified in the query. These criteria can include matching keywords orspecific values for certain fields. The searching operations at step 608may use the late-binding schema to extract values for specified fieldsfrom events at the time the query is processed. In an embodiment, one ormore rules for extracting field values may be specified as part of asource type definition. The indexers may then either send the relevantresults back to the search head, or use the results to determine apartial result and send the partial result back to the search head.

At step 610, the search head combines the partial results and/or eventsreceived from the indexers to produce a final result for the query. Thisfinal result may comprise different types of data depending on what thequery requested. For example, the results can include a listing ofmatching events returned by the query, or some type of visualization ofthe data from the returned events. In another example, the final resultcan include one or more calculated values derived from the matchingevents.

The results generated by the system 32 can be returned to a client usingdifferent techniques. For example, one technique streams results orrelevant events back to a client in real-time as they are identified.Another technique waits to report the results to the client until acomplete set of results (which may include a set of relevant events or aresult based on relevant events) is ready to return to the client. Yetanother technique streams interim results or relevant events back to theclient in real-time until a complete set of results is ready and thenreturns the complete set of results to the client. In another technique,certain results are stored as “search jobs,” and the client may retrievethe results by referring to the search jobs.

The search head can also perform various operations to make the searchmore efficient. For example, before the search head begins execution ofa query, the search head can determine a time range for the query and aset of common keywords that all matching events include. The search headmay then use these parameters to query the indexers to obtain a supersetof the eventual results. Then, during a filtering stage, the search headcan perform field-extraction operations on the superset to produce areduced set of search results. This speeds up queries that are performedon a periodic basis.

2.7. Field Extraction

The search head 50 allows users to search and visualize event dataextracted from raw machine data received from homogenous data sources.It also allows users to search and visualize event data extracted fromraw machine data received from heterogeneous data sources. The searchhead 50 includes various mechanisms, which may additionally reside in anindexer 46, for processing a query. Splunk Processing Language (SPL),used in conjunction with the SPLUNK® ENTERPRISE system, can be utilizedto make a query. SPL is a pipelined search language in which a set ofinputs is operated on by a first command in a command line, and then asubsequent command following the pipe symbol “|” operates on the resultsproduced by the first command, and so on, for additional commands. Otherquery languages, such as the Structured Query Language (“SQL”), can beused to create a query.

In response to receiving the search query, search head 50 usesextraction rules to extract values for the fields associated with afield or fields in the event data being searched. The search head 50obtains extraction rules that specify how to extract a value for certainfields from an event. Extraction rules can comprise regex rules thatspecify how to extract values for the relevant fields. In addition tospecifying how to extract field values, the extraction rules may alsoinclude instructions for deriving a field value by performing a functionon a character string or value retrieved by the extraction rule. Forexample, a transformation rule may truncate a character string, orconvert the character string into a different data format. In somecases, the query itself can specify one or more extraction rules.

The search head 50 can apply the extraction rules to event data that itreceives from indexers 46. Indexers 46 may apply the extraction rules toevents in an associated data store 48. Extraction rules can be appliedto all the events in a data store, or to a subset of the events thathave been filtered based on some criteria (e.g., event time stampvalues, etc.). Extraction rules can be used to extract one or morevalues for a field from events by parsing the event data and examiningthe event data for one or more patterns of characters, numbers,delimiters, etc., that indicate where the field begins and, optionally,ends.

FIG. 7 illustrates an example of raw machine data received fromdisparate data sources. In this example, a user submits an order formerchandise using a vendor's shopping application program 52 running onthe user's system. In this example, the order was not delivered to thevendor's server due to a resource exception at the destination serverthat is detected by the middleware code 54. The user then sends amessage to the customer support 56 to complain about the order failingto complete. The three systems 52, 54, and 56 are disparate systems thatdo not have a common logging format. The order application 52 sends logdata 58 to the SPLUNK® ENTERPRISE system in one format, the middlewarecode 54 sends error log data 60 in a second format, and the supportserver 56 sends log data 62 in a third format.

Using the log data received at one or more indexers 46 from the threesystems the vendor can uniquely obtain an insight into user activity,user experience, and system behavior. The search head 50 allows thevendor's administrator to search the log data from the three systemsthat one or more indexers 46 are responsible for searching, therebyobtaining correlated information, such as the order number andcorresponding customer ID number of the person placing the order. Thesystem also allows the administrator to see a visualization of relatedevents via a user interface. The administrator can query the search head50 for customer ID field value matches across the log data from thethree systems that are stored at the one or more indexers 46. Thecustomer ID field value exists in the data gathered from the threesystems, but the customer ID field value may be located in differentareas of the data given differences in the architecture of thesystems—there is a semantic relationship between the customer ID fieldvalues generated by the three systems. The search head 50 requests eventdata from the one or more indexers 46 to gather relevant event data fromthe three systems. It then applies extraction rules to the event data inorder to extract field values that it can correlate. The search head mayapply a different extraction rule to each set of events from each systemwhen the event data format differs among systems. In this example, theuser interface can display to the administrator the event datacorresponding to the common customer ID field values 64, 66, and 68,thereby providing the administrator with insight into a customer'sexperience.

Note that query results can be returned to a client, a search head, orany other system component for further processing. In general, queryresults may include a set of one or more events, a set of one or morevalues obtained from the events, a subset of the values, statisticscalculated based on the values, a report containing the values, or avisualization, such as a graph or chart, generated from the values.

2.8. Example Search Screen

FIG. 8A illustrates an example search screen 70 in accordance with thedisclosed embodiments. Search screen 70 includes a search bar 72 thataccepts user input in the form of a search string. It also includes atime range picker 74 that enables the user to specify a time range forthe search. For “historical searches” the user can select a specifictime range, or alternatively a relative time range, such as “today,”“yesterday” or “last week.” For “real-time searches,” the user canselect the size of a preceding time window to search for real-timeevents. Search screen 600 also initially displays a “data summary”dialog as is illustrated in FIG. 8B that enables the user to selectdifferent sources for the event data, such as by selecting specifichosts and log files.

After the search is executed, the search screen 70 in FIG. 8A candisplay the results through search results tabs 76, wherein searchresults tabs 76 includes: an “events tab” that displays variousinformation about events returned by the search; a “statistics tab” thatdisplays statistics about the search results; and a “visualization tab”that displays various visualizations of the search results. The eventstab illustrated in FIG. 8A displays a timeline graph 78 that graphicallyillustrates the number of events that occurred in one-hour intervalsover the selected time range. It also displays an events list 80 thatenables a user to view the raw data in each of the returned events. Itadditionally displays a fields sidebar 81 that includes statistics aboutoccurrences of specific fields in the returned events, including“selected fields” that are pre-selected by the user, and “interestingfields” that are automatically selected by the system based onpre-specified criteria.

2.9. Data Models

A data model is a hierarchically structured search-time mapping ofsemantic knowledge about one or more datasets. It encodes the domainknowledge necessary to build a variety of specialized searches of thosedatasets. Those searches, in turn, can be used to generate reports.

A data model is composed of one or more “objects” (or “data modelobjects”) that define or otherwise correspond to a specific set of data.

Objects in data models can be arranged hierarchically in parent/childrelationships. Each child object represents a subset of the datasetcovered by its parent object. The top-level objects in data models arecollectively referred to as “root objects.”

Child objects have inheritance. Data model objects are defined bycharacteristics that mostly break down into constraints and attributes.Child objects inherit constraints and attributes from their parentobjects and have additional constraints and attributes of their own.Child objects provide a way of filtering events from parent objects.Because a child object always provides an additional constraint inaddition to the constraints it has inherited from its parent object, thedataset it represents is always a subset of the dataset that its parentrepresents.

For example, a first data model object may define a broad set of datapertaining to e-mail activity generally, and another data model objectmay define specific datasets within the broad dataset, such as a subsetof the e-mail data pertaining specifically to e-mails sent. Examples ofdata models can include electronic mail, authentication, databases,intrusion detection, malware, application state, alerts, computeinventory, network sessions, network traffic, performance, audits,updates, vulnerabilities, etc. Data models and their objects can bedesigned by knowledge managers in an organization, and they can enabledownstream users to quickly focus on a specific set of data. Forexample, a user can simply select an “e-mail activity” data model objectto access a dataset relating to e-mails generally (e.g., sent orreceived), or select an “e-mails sent” data model object (or datasub-model object) to access a dataset relating to e-mails sent.

A data model object may be defined by (1) a set of search constraints,and (2) a set of fields. Thus, a data model object can be used toquickly search data to identify a set of events and to identify a set offields to be associated with the set of events. For example, an “e-mailssent” data model object may specify a search for events relating toe-mails that have been sent and specify a set of fields that areassociated with the events. Thus, a user can retrieve and use the“e-mails sent” data model object to quickly search source data forevents relating to sent e-mails, and the user may be provided with alisting of the set of fields relevant to the events in a user interfacescreen.

A child of the parent data model may be defined by a search (typically anarrower search) that produces a subset of the events that would beproduced by the parent data model's search. The child's set of fieldscan include a subset of the set of fields of the parent data modeland/or additional fields. Data model objects that reference the subsetscan be arranged in a hierarchical manner, so that child subsets ofevents are proper subsets of their parents. A user iteratively applies amodel development tool (not shown in FIG.) to prepare a query thatdefines a subset of events and assigns an object name to that subset. Achild subset is created by further limiting a query that generated aparent subset. A late-binding schema of field extraction rules isassociated with each object or subset in the data model.

Data definitions in associated schemas can be taken from the commoninformation model (CIM) or can be devised for a particular schema andoptionally added to the CIM. Child objects inherit fields from parentsand can include fields not present in parents. A model developer canselect fewer extraction rules than are available for the sourcesreturned by the query that defines events belonging to a model.Selecting a limited set of extraction rules can be a tool forsimplifying and focusing the data model, while allowing a userflexibility to explore the data subset. Development of a data model isfurther explained in U.S. Pat. Nos. 8,788,525 and 8,788,526, bothentitled “DATA MODEL FOR MACHINE DATA FOR SEMANTIC SEARCH”, both issuedon 22 Jul. 2014, U.S. Pat. No. 8,983,994, entitled “GENERATION OF A DATAMODEL FOR SEARCHING MACHINE DATA”, issued on 17 Mar. 2015, U.S. patentapplication Ser. No. 14/611,232, entitled “GENERATION OF A DATA MODELAPPLIED TO QUERIES”, filed on 31 Jan. 2015, and U.S. patent applicationSer. No. 14/815,884, entitled “GENERATION OF A DATA MODEL APPLIED TOOBJECT QUERIES”, filed on 31 Jul. 2015, each of which is herebyincorporated by reference in its entirety for all purposes. See, also,Knowledge Manager Manual, Build a Data Model, Splunk Enterprise 6.1.3pp. 150-204 (Aug. 25, 2014).

A data model can also include reports. One or more report formats can beassociated with a particular data model and be made available to runagainst the data model. A user can use child objects to design reportswith object datasets that already have extraneous data pre-filtered out.In an embodiment, the data intake and query system 32 provides the userwith the ability to produce reports (e.g., a table, chart,visualization, etc.) without having to enter SPL, SQL, or other querylanguage terms into a search screen. Data models are used as the basisfor the search feature.

Data models may be selected in a report generation interface. The reportgenerator supports drag-and-drop organization of fields to be summarizedin a report. When a model is selected, the fields with availableextraction rules are made available for use in the report. The user mayrefine and/or filter search results to produce more precise reports. Theuser may select some fields for organizing the report and select otherfields for providing detail according to the report organization. Forexample, “region” and “salesperson” are fields used for organizing thereport and sales data can be summarized (subtotaled and totaled) withinthis organization. The report generator allows the user to specify oneor more fields within events and apply statistical analysis on valuesextracted from the specified one or more fields. The report generatormay aggregate search results across sets of events and generatestatistics based on aggregated search results. Building reports usingthe report generation interface is further explained in U.S. patentapplication Ser. No. 14/503,335, entitled “GENERATING REPORTS FROMUNSTRUCTURED DATA”, filed on 30 Sep. 2014, and which is herebyincorporated by reference in its entirety for all purposes, and in PivotManual, Splunk Enterprise 6.1.3 (Aug. 4, 2014). Data visualizations alsocan be generated in a variety of formats, by reference to the datamodel. Reports, data visualizations, and data model objects can be savedand associated with the data model for future use. The data model objectmay be used to perform searches of other data.

FIGS. 14, 15, and 9A through 9D illustrate a series of user interfacescreens where a user may select report generation options using datamodels. The report generation process may be driven by a predefined datamodel object, such as a data model object defined and/or saved via areporting application or a data model object obtained from anothersource. A user can load a saved data model object using a report editor.For example, the initial search query and fields used to drive thereport editor may be obtained from a data model object. The data modelobject that is used to drive a report generation process may define asearch and a set of fields. Upon loading of the data model object, thereport generation process may enable a user to use the fields (e.g., thefields defined by the data model object) to define criteria for a report(e.g., filters, split rows/columns, aggregates, etc.) and the search maybe used to identify events (e.g., to identify events responsive to thesearch) used to generate the report. That is, for example, if a datamodel object is selected to drive a report editor, the graphical userinterface of the report editor may enable a user to define reportingcriteria for the report using the fields associated with the selecteddata model object, and the events used to generate the report may beconstrained to the events that match, or otherwise satisfy, the searchconstraints of the selected data model object.

The selection of a data model object for use in driving a reportgeneration may be facilitated by a data model object selectioninterface. FIG. 14 illustrates an example interactive data modelselection graphical user interface 84 of a report editor that displays alisting of available data models 86. The user may select one of the datamodels 88.

FIG. 15 illustrates an example data model object selection graphicaluser interface 90 that displays available data objects 92 for theselected data object model 88. The user may select one of the displayeddata model objects 94 for use in driving the report generation process.

Once a data model object is selected by the user, a user interfacescreen 96 shown in FIG. 9A may display an interactive listing ofautomatic field identification options 98 based on the selected datamodel object. For example, a user may select one of the threeillustrated options (e.g., the “All Fields” option 100, the “SelectedFields” option 102, or the “Coverage” option (e.g., fields with at leasta specified % of coverage) 104). If the user selects the “All Fields”option 100, all of the fields identified from the events that werereturned in response to an initial search query may be selected. Thatis, for example, all of the fields of the identified data model objectfields may be selected. If the user selects the “Selected Fields” option102, only the fields from the fields of the identified data model objectfields that are selected by the user may be used. If the user selectsthe “Coverage” option 104, only the fields of the identified data modelobject fields meeting a specified coverage criteria may be selected. Apercent coverage may refer to the percentage of events returned by theinitial search query that a given field appears in. Thus, for example,if an object dataset includes 10,000 events returned in response to aninitial search query, and the “avg_age” field appears in 854 of those10,000 events, then the “avg_age” field would have a coverage of 8.54%for that object dataset. If, for example, the user selects the“Coverage” option and specifies a coverage value of 2%, only fieldshaving a coverage value equal to or greater than 2% may be selected. Thenumber of fields corresponding to each selectable option may bedisplayed in association with each option. For example, “97” displayednext to the “All Fields” option 100 indicates that 97 fields will beselected if the “All Fields” option is selected. The “3” displayed nextto the “Selected Fields” option 102 indicates that 3 of the 97 fieldswill be selected if the “Selected Fields” option is selected. The “49”displayed next to the “Coverage” option 104 indicates that 49 of the 97fields (e.g., the 49 fields having a coverage of 2% or greater) will beselected if the “Coverage” option is selected. The number of fieldscorresponding to the “Coverage” option may be dynamically updated basedon the specified percent of coverage.

FIG. 9B illustrates an example graphical user interface screen (alsocalled the pivot interface) 106 displaying the reporting application's“Report Editor” page. The screen may display interactive elements fordefining various elements of a report. For example, the page includes a“Filters” element 108, a “Split Rows” element 110, a “Split Columns”element 112, and a “Column Values” element 114. The page may include alist of search results 118. In this example, the Split Rows element 110is expanded, revealing a listing of fields 116 that can be used todefine additional criteria (e.g., reporting criteria). The listing offields 116 may correspond to the selected fields (attributes). That is,the listing of fields 116 may list only the fields previously selected,either automatically and/or manually by a user. FIG. 9C illustrates aformatting dialogue 120 that may be displayed upon selecting a fieldfrom the listing of fields 116. The dialogue can be used to format thedisplay of the results of the selection (e.g., label the column to bedisplayed as “component”).

FIG. 9D illustrates an example graphical user interface screen 106including a table of results 122 based on the selected criteriaincluding splitting the rows by the “component” field. A column 124having an associated count for each component listed in the table may bedisplayed that indicates an aggregate count of the number of times thatthe particular field-value pair (e.g., the value in a row) occurs in theset of events responsive to the initial search query.

FIG. 16 illustrates an example graphical user interface screen 126 thatallows the user to filter search results and to perform statisticalanalysis on values extracted from specific fields in the set of events.In this example, the top ten product names ranked by price are selectedas a filter 128 that causes the display of the ten most popular productssorted by price. Each row is displayed by product name and price 130.This results in each product displayed in a column labeled “productname” along with an associated price in a column labeled “price” 138.Statistical analysis of other fields in the events associated with theten most popular products have been specified as column values 132. Acount of the number of successful purchases for each product isdisplayed in column 134. This statistics may be produced by filteringthe search results by the product name, finding all occurrences of asuccessful purchase in a field within the events, and generating a totalof the number of occurrences. A sum of the total sales is displayed incolumn 136, which is a result of the multiplication of the price and thenumber of successful purchases for each product.

The reporting application allows the user to create graphicalvisualizations of the statistics generated for a report. For example,FIG. 17 illustrates an example graphical user interface 140 thatdisplays a set of components and associated statistics 142. Thereporting application allows the user to select a visualization of thestatistics in a graph (e.g., bar chart, scatter plot, area chart, linechart, pie chart, radial gauge, marker gauge, filler gauge, etc.). FIG.18 illustrates an example of a bar chart visualization 144 of an aspectof the statistical data 142. FIG. 19 illustrates a scatter plotvisualization 146 of an aspect of the statistical data 142.

2.10. Acceleration Technique

The above-described system provides significant flexibility by enablinga user to analyze massive quantities of minimally processed data “on thefly” at search time instead of storing pre-specified portions of thedata in a database at ingestion time. This flexibility enables a user tosee valuable insights, correlate data, and perform subsequent queries toexamine interesting aspects of the data that may not have been apparentat ingestion time.

However, performing extraction and analysis operations at search timecan involve a large amount of data and require a large number ofcomputational operations, which can cause delays in processing thequeries. Advantageously, SPLUNK® ENTERPRISE system employs a number ofunique acceleration techniques that have been developed to speed upanalysis operations performed at search time. These techniques include:(1) performing search operations in parallel across multiple indexers;(2) using a keyword index (e.g., lexicon); (3) using a high performanceanalytics store; and (4) accelerating the process of generating reports.These novel techniques are described in more detail below.

2.10.1. Aggregation Technique

To facilitate faster query processing, a query can be structured suchthat multiple indexers perform the query in parallel, while aggregationof search results from the multiple indexers is performed locally at thesearch head. For example, FIG. 10 illustrates how a search query 148received from a client at a search head 50 can split into two phases,including: (1) subtasks 150 (e.g., data retrieval or simple filtering)that may be performed in parallel by indexers 46 for execution, and (2)a search results aggregation operation 152 to be executed by the searchhead when the results are ultimately collected from the indexers.

During operation, upon receiving search query 148, a search head 50determines that a portion of the operations involved with the searchquery may be performed locally by the search head. The search headmodifies search query 148 by substituting “stats” (create aggregatestatistics over results sets received from the indexers at the searchhead) with “prestats” (create statistics by the indexer from localresults set) to produce search query 150, and then distributes searchquery 148 to distributed indexers, which are also referred to as “searchpeers.” Note that search queries may generally specify search criteriaor operations to be performed on events that meet the search criteria.Search queries may also specify field names, as well as search criteriafor the values in the fields or operations to be performed on the valuesin the fields. Moreover, the search head may distribute the full searchquery to the search peers as illustrated in FIG. 6, or may alternativelydistribute a modified version (e.g., a more restricted version) of thesearch query to the search peers. In this example, the indexers areresponsible for producing the results and sending them to the searchhead. After the indexers return the results to the search head, thesearch head aggregates the received results 152 to form a single searchresult set. By executing the query in this manner, the systemeffectively distributes the computational operations across the indexerswhile minimizing data transfers.

2.10.2. Keyword Index

As described above with reference to the flow charts in FIG. 5 and FIG.6, data intake and query system 32 can construct and maintain one ormore keyword indices (e.g., lexicons) to quickly identify eventscontaining specific keywords. This technique can greatly speed up theprocessing of queries involving specific keywords. As mentioned above,to build a keyword index, an indexer first identifies a set of keywords.Then, the indexer includes the identified keywords in an index (e.g., atime-series index), which associates each stored keyword with referencesto events containing that keyword, or to locations within events wherethat keyword is located. When an indexer subsequently receives akeyword-based query, the indexer can access the keyword index to quicklyidentify events containing the keyword.

2.10.3. High Performance Analytics Store

To speed up certain types of queries, some embodiments of the system 32create a high performance analytics store, which can be referred to as a“summarization table,” that contains entries for specific field-valuepairs. A summarization table may be populated in response to a searchquery applied to events. The system can then use the summarization tableto accelerate subsequent queries related to the events subject to theoriginal search query. As such, the system can accelerate the subsequentqueries by using the data contained in the summarization table to returnsearch results, while avoiding the processing otherwise required toobtain the original search results. For example, the system 32 mayreceive a search query for events that have specified keywords. Asummarization table produced in response to the search query can be usedfor perform subsequent statistical queries related to the eventsincluding the specified keywords.

The summarization tables can be populated at search time. The basis forthe summarization tables are time-series index (tsidx) files that arepopulated at index time. The tsidx files are populated at index time tofacilitate searching of events, as detailed above. Hence, thesummarization tables built from the tsidx files can speed up certaintypes of queries. A tsidx file is a self-contained file populated withdata extracted at index time from events. The tsidx file can associatefield values (e.g., keywords) of events with location references to theevents, which are stored in a companion journal file. For example, atindex time, events can be processed to extract time values, metadatafield values, user specified field values, other field values, etc. Thesystem populates a tsidx file with the extracted time values and fieldvalues, and stores the actual events in a journal. The tsidx file isused to process a received search query having search criteria includingthe indexed events. The tsidx file then facilitates rapidly searchingthe events stored in the journal.

The structure and contents of a tsidx file facilitate searching data ofevents stored in a companion journal. In some embodiments, the structureof the tsidx file includes distinct sections. A section of the tsidxfile includes an array of time values (e.g., timestamps) extracted fromevents. Another section includes event identifiers and informationidentifying the locations of respective events in the journal. Anothersection can include a lexicon (e.g., keyword index) of the field valuesextracted from the events. The lexicon may include field valuesidentified at index time. The lexicon may also include user definedcustomized field values and/or combinations of field values identifiedat index time. The lexicon may also contain meta-field values such as asource, source type, or host values of the events. Another section ofthe tsidx file can include postings that map the field values in thelexicon to event identifiers.

The data entries of the sections can be structured to map data entriesin one section to data entries in another section. In some embodiments,data entries contained in one section can be ordered in the same way asrelated data entries in another section. For example, the lexicon mayinclude N entries in N rows. The posting map can also include N entriesin N rows such that the kth entry in the lexicon matches the kth entryof the posting. In some embodiments, the data entries in sections caninclude explicit pointers to data entries in other sections of the tsidxfile. For example, the lexicon can include N field value entries in Nrows, and the postings map can include N event identifier entries in Nrows. The event identifier can map to the event identifiers sectionincluding associated locations information to retrieve data from eventsstored in the journal. Thus, the structure of the tsidx file and thestructure of its sections create paths that facilities searching eventsduring search time.

During search time, a query may include criteria that specify fieldvalues (e.g., meta-field values) contained in the lexicon of the tsidxfile. The lexicon is searched to identify the specified field values.The locations of the particular entries in the lexicon that contain thespecified field values can be used to identify corresponding entries inthe postings map, which can include references to event identifiers inthe corresponding section of the tsidx file. Then, configuration filesfor the identified events can be retrieved and used to extract data fromthe events. For example, the configuration files may define extractionrules that are event source or source type specific, and thoseextraction rules can be used to extract data from the events.

For example, the search criteria of a search query may include IPaddresses of events that include the value “94107” for a “ZIP code”field. The system can search the lexicon of the tsidx for the specifiedfield value. The third entry of the lexicon may include a specifiedfield value, and the corresponding third entry of the posting list mayidentify two events. The event identifiers in the third entry of thepostings are used to identify the location information of the eventsincluding the value “94107” for the “ZIP code” field. The configurationfiles of identified events are retrieved, and their extraction rules areused to extract the IP addresses from the identified events. As such,the IP addresses or events that satisfy the search query can beretrieved using the tsidx file.

Thus, when the system 32 receives a search query, the system 32 will runscans on the tsidx files for the search criteria, and uses locationreferences to retrieve events that satisfy the search criteria from thejournal file. In some embodiments, each “bucket” or events includes itsown tsidx file and companion journal. As such, processing a search querymay require scanning the tsidx files of multiple buckets to obtainpartial search results that are aggregated to obtain the search resultsthat satisfy the search query. In some embodiments, to speed upsearches, bloom filters can be used to narrow the set of tsidx filesthat the system 32 must search to obtain search results.

In some embodiments, the process for searching events detailed above isrepeated for each search query. Hence, even though the use of tsidxfiles enhances searching by avoiding the need to search all events,using the tsidx files for searching over events for certain queries canbe inefficient. For example, a first query may specify keywords, andtsidx files can be used to retrieve events that contain those keywords.A second query may specify a statistical analysis to be performed ofevents that contain the keywords of the first query. As such, performingthe second query would require at least the same steps performed for thefirst search query, and additional steps to complete the statisticalanalysis. Accordingly, performing the second subsequent query isinefficient because it fails to take advantage of the execution of thefirst query.

To speed up certain types of queries, some embodiments of the system 32create the summarization tables, which contain entries for specificfield values. This optimization mechanism can be initiated automaticallyor manually by a user to create summarization tables on a per search,per bucket basis. For example, a user can set a data model toautomatically generate and use summarization tables to perform thespecialized searches. In another example, a user can submit a commandthrough a user interface to accelerate query processing by usingsummarization tables. Then, upon receiving search queries, the systemcan generate and scan summarization tables to accelerate searches. Forexample, a user can add SPL commands to a search field causing a searchto operate on the summarization table, and the results can be quicklyobtained by avoiding the need to consult configuration files, extractionrules, etc.

At search time, summarization tables are generated based on the tsidxfiles. In particular, a summarization table is populated based on eventsretrieved during search time, in response to a search query. In someembodiments, the size of the summarization table may be derived based onthe configuration files for events retrieved as search time. Forexample, each source type definition may have one or more configurationfiles that define all the extraction rules that can be used to extractfield values from events of that source type. In another example, theconfiguration files can define the extraction rules for a source oranother meta field.

The configuration files for events retrieved at search time can be usedto populate a summarization table by applying all the extraction rulesof the retrieved events to the retrieved events. For example, the system32 would identify configuration files for the source types matching theretrieved events. The system can apply some or all the extraction rulesto extract some or all the field values that are extractable based onthe extraction rules defined by the configuration files. Thesummarization table can then be populated with all the event data fromthe tsidx file retrieved during search time and all other field valuesof those events identified from their configuration files.

In some embodiments, the resulting summarization table can have acolumnar structure where data is stored in columns instead of rows.Specifically, each column may correspond to a field type of the eventsretrieved at search time. In some embodiments, where events identifiedat search time have different configuration files, the summarizationtable may include cells that are empty. Specifically, the retrievedevents may be associated with different source types that have differentconfiguration files defining different extraction rules. As a result,some cells of the summarization table are empty because the extractionrules used to extract data from some events may not be relevant to allevents.

Thus, a summarization table includes the search results obtained byscanning a tsidx file and is enriched by the field values determined inaccordance with the extraction rules of the configuration files forretrieved events. More specifically, the summarization table may containmultiple entries including specific values from specific fields of theevent data. The extracted field values satisfy the search criteria ofthe query received by the system, and may also include other fieldvalues that do not satisfy the specific criteria but which wereextracted from events including the field values that do satisfy thecriteria. The summarization table may also include other data related tothe query processed by the system. Thus, the field values of thesummarization table form a lexicon of where at least some columns of thesummarization table map to the row of the tsidx file. As such, the tsidxfile from which the summarization table was derived can itself bederived from the summarization data.

In some embodiments, the summarization table may not include informationindicative of the locations of events in the journal if all the fieldvalues of those events are included in the summarization table. As aresult, scanning the summarization table to obtain results eliminatesthe need to access events stored in the journal. As such, searchesperformed on data contained in the summarization table are acceleratedbecause the configuration files for events do not need to be consultedand the events themselves do not need to be retrieved form the journal.

For example, a search query may have search criteria including IPaddresses of events having value of “94107” for a “ZIP code” field ofevents. The system could automatically populate a summarization tablewith multiple entries including entries based on the events that includethe specified field values. The summarization table is also enrichedwith all other field values that could be extracted from the eventsbased on their configuration files. Thus, the summarization tableincludes the search results and other field values that are not part ofthe search results. Moreover, the summarization table can be used toreconstruct the tsidx file itself from which the search results wereobtained.

The disclosed embodiments enable the system 32 to quickly processsubsequent queries that can use the data contained in the summarizationtable rather than searching the events data all over again via the tsidxfile. Examples of the subsequent queries may involve statisticalanalysis of field values that are included in the summarization table.Thus, rather than performing another search and extraction process onthe events, the system can use the summarization table to perform theadditional statistical analysis.

The system 32 can use the summarization table to return results for aquery rather than needing to perform extraction operations on events toboth extract field values and perform a statistical analysis of thefield values. For example, a user may seek to perform a statisticalanalysis of events that include particular values in particular fields.To this end, the system can evaluate entries in the summarization tableto perform a statistical analysis on specific values in the specificfields without having to go through the individual events or performdata extractions at search time.

For example, the system may receive a query specifying criteriaincluding a count of events that have the value “94107” in the “ZIPcode” field. Without the summarization table, the system would need tosearch and extract the raw data of the events that satisfy the searchcriteria and perform a count of specified field values pairs as searchresults. However, the system 32 can instead evaluate entries in thesummarization table to count instances of “94107” in the “ZIP code”field without having to go through the individual events or perform dataextractions at search time. Thus, the disclosed embodiments can speed upobtaining results for these types of queries.

In some embodiments, the system 32 can maintain a separate summarizationtable for each of the above-described time-specific buckets that storesevents for a specific time range. A bucket-specific summarization tableincludes entries for specific field value combinations that occur inevents in the specific bucket. In some embodiments, the system 32 canmaintain a separate summarization table for each indexer. Theindexer-specific summarization table includes entries for the events ina data store that are managed by the specific indexer. Indexer-specificsummarization tables may also be bucket-specific. However, the disclosedembodiments are not so limited. Instead, summarization tables can bedefined based on any range or parameter used to limit a searchoperation.

In some embodiments, a summarization table can include references toevents from which its field values were extracted. If the system needsto process all events that have a specific field-value combination, thesystem can use the references in the summarization table entry todirectly access the events from the journal. For example, when thesummarization tables may not cover all of the events that are relevantto a subsequent query, the system can use the summarization tables toobtain partial results for the events that are covered by summarizationtables, but may also have to search through other events that are notcovered by the summarization tables to produce additional results. Theseadditional results can then be combined with the partial results toproduce a final set of results for the query.

Some aspects of the summarization table and associated techniques aredescribed in more detail in U.S. Pat. No. 8,682,925, entitled“DISTRIBUTED HIGH PERFORMANCE ANALYTICS STORE”, issued on 25 Mar. 2014,U.S. patent application Ser. No. 14/170,159, entitled “SUPPLEMENTING AHIGH PERFORMANCE ANALYTICS STORE WITH EVALUATION OF INDIVIDUAL EVENTS TORESPOND TO AN EVENT QUERY”, filed on 31 Jan. 2014, and U.S. patentapplication Ser. No. 14/815,973, entitled “STORAGE MEDIUM AND CONTROLDEVICE”, filed on 21 Feb. 2014, each of which is hereby incorporated byreference in its entirety.

2.10.4. Accelerating Report Generation

In some embodiments, a data server system such as the SPLUNK® ENTERPRISEsystem can accelerate the process of periodically generating updatedreports based on query results. To accelerate this process, asummarization engine automatically examines the query to determinewhether generation of updated reports can be accelerated by creatingintermediate summaries. If reports can be accelerated, the summarizationengine periodically generates a summary covering data obtained during alatest non-overlapping time period. For example, where the query seeksevents meeting a specified criteria, a summary for the time periodincludes only events within the time period that meet the specifiedcriteria. Similarly, if the query seeks statistics calculated from theevents, such as the number of events that match the specified criteria,then the summary for the time period includes the number of events inthe period that match the specified criteria.

In addition to the creation of the summaries, the summarization engineschedules the periodic updating of the report associated with the query.During each scheduled report update, the query engine determines whetherintermediate summaries have been generated covering portions of the timeperiod covered by the report update. If so, then the report is generatedbased on the information contained in the summaries. Also, if additionalevent data has been received and has not yet been summarized, and isrequired to generate the complete report, the query can be run on thisadditional event data. Then, the results returned by this query on theadditional event data, along with the partial results obtained from theintermediate summaries, can be combined to generate the updated report.This process is repeated each time the report is updated. Alternatively,if the system stores events in buckets covering specific time ranges,then the summaries can be generated on a bucket-by-bucket basis. Notethat producing intermediate summaries can save the work involved inre-running the query for previous time periods, so, advantageously, onlythe newer event data needs to be processed while generating an updatedreport. These report acceleration techniques are described in moredetail in U.S. Pat. No. 8,589,403, entitled “COMPRESSED JOURNALING INEVENT TRACKING FILES FOR METADATA RECOVERY AND REPLICATION”, issued on19 Nov. 2013, U.S. Pat. No. 8,412,696, entitled “REAL TIME SEARCHING ANDREPORTING”, issued on 2 Apr. 2011, and U.S. Pat. Nos. 8,589,375 and8,589,432, both also entitled “REAL TIME SEARCHING AND REPORTING”, bothissued on 19 Nov. 2013, each of which is hereby incorporated byreference in its entirety.

2.11. Security Features

The SPLUNK® ENTERPRISE platform provides various schemas, dashboards andvisualizations that simplify developers' task to create applicationswith additional capabilities. One such application is the SPLUNK® APPFOR ENTERPRISE SECURITY, which performs monitoring and alertingoperations and includes analytics to facilitate identifying both knownand unknown security threats based on large volumes of data stored bythe SPLUNK® ENTERPRISE system. SPLUNK® APP FOR ENTERPRISE SECURITYprovides the security practitioner with visibility intosecurity-relevant threats found in the enterprise infrastructure bycapturing, monitoring, and reporting on data from enterprise securitydevices, systems, and applications. Through the use of SPLUNK®ENTERPRISE searching and reporting capabilities, SPLUNK® APP FORENTERPRISE SECURITY provides a top-down and bottom-up view of anorganization's security posture.

The SPLUNK® APP FOR ENTERPRISE SECURITY leverages SPLUNK® ENTERPRISEsearch-time normalization techniques, saved searches, and correlationsearches to provide visibility into security-relevant threats andactivity and generate notable events for tracking. The App enables thesecurity practitioner to investigate and explore the data to find new orunknown threats that do not follow signature-based patterns.

Conventional Security Information and Event Management (SIEM) systemsthat lack the infrastructure to effectively store and analyze largevolumes of security-related data. Traditional SIEM systems typically usefixed schemas to extract data from pre-defined security-related fieldsat data ingestion time and storing the extracted data in a relationaldatabase. This traditional data extraction process (and associatedreduction in data size) that occurs at data ingestion time inevitablyhampers future incident investigations that may need original data todetermine the root cause of a security issue, or to detect the onset ofan impending security threat.

In contrast, the SPLUNK® APP FOR ENTERPRISE SECURITY system stores largevolumes of minimally processed security-related data at ingestion timefor later retrieval and analysis at search time when a live securitythreat is being investigated. To facilitate this data retrieval process,the SPLUNK® APP FOR ENTERPRISE SECURITY provides pre-specified schemasfor extracting relevant values from the different types ofsecurity-related event data and enables a user to define such schemas.

The SPLUNK® APP FOR ENTERPRISE SECURITY can process many types ofsecurity-related information. In general, this security-relatedinformation can include any information that can be used to identifysecurity threats. For example, the security-related information caninclude network-related information, such as IP addresses, domain names,asset identifiers, network traffic volume, uniform resource locatorstrings, and source addresses. The process of detecting security threatsfor network-related information is further described in U.S. Pat. No.8,826,434, entitled “SECURITY THREAT DETECTION BASED ON INDICATIONS INBIG DATA OF ACCESS TO NEWLY REGISTERED DOMAINS”, issued on 2 Sep. 2014,U.S. patent application Ser. No. 13/956,252, entitled “INVESTIGATIVE ANDDYNAMIC DETECTION OF POTENTIAL SECURITY-THREAT INDICATORS FROM EVENTS INBIG DATA”, filed on 31 Jul. 2013, U.S. patent application Ser. No.14/445,018, entitled “GRAPHIC DISPLAY OF SECURITY THREATS BASED ONINDICATIONS OF ACCESS TO NEWLY REGISTERED DOMAINS”, filed on 28 Jul.2014, U.S. patent application Ser. No. 14/445,023, entitled “SECURITYTHREAT DETECTION OF NEWLY REGISTERED DOMAINS”, filed on 28 Jul. 2014,U.S. patent application Ser. No. 14/815,971, entitled “SECURITY THREATDETECTION USING DOMAIN NAME ACCESSES”, filed on 1 Aug. 2015, and U.S.patent application Ser. No. 14/815,972, entitled “SECURITY THREATDETECTION USING DOMAIN NAME REGISTRATIONS”, filed on 1 Aug. 2015, eachof which is hereby incorporated by reference in its entirety for allpurposes. Security-related information can also include malwareinfection data and system configuration information, as well as accesscontrol information, such as login/logout information and access failurenotifications. The security-related information can originate fromvarious sources within a data center, such as hosts, virtual machines,storage devices and sensors. The security-related information can alsooriginate from various sources in a network, such as routers, switches,email servers, proxy servers, gateways, firewalls andintrusion-detection systems.

During operation, the SPLUNK® APP FOR ENTERPRISE SECURITY facilitatesdetecting “notable events” that are likely to indicate a securitythreat. These notable events can be detected in a number of ways: (1) auser can notice a correlation in the data and can manually identify acorresponding group of one or more events as “notable;” or (2) a usercan define a “correlation search” specifying criteria for a notableevent, and every time one or more events satisfy the criteria, theapplication can indicate that the one or more events are notable. A usercan alternatively select a pre-defined correlation search provided bythe application. Note that correlation searches can be run continuouslyor at regular intervals (e.g., every hour) to search for notable events.Upon detection, notable events can be stored in a dedicated “notableevents index,” which can be subsequently accessed to generate variousvisualizations containing security-related information. Also, alerts canbe generated to notify system operators when important notable eventsare discovered.

The SPLUNK® APP FOR ENTERPRISE SECURITY provides various visualizationsto aid in discovering security threats, such as a “key indicators view”that enables a user to view security metrics, such as counts ofdifferent types of notable events. For example, FIG. 11A illustrates anexample key indicators view 154 that comprises a dashboard, which candisplay a value 156, for various security-related metrics, such asmalware infections 158. It can also display a change in a metric value160, which indicates that the number of malware infections increased by63 during the preceding interval. Key indicators view 154 additionallydisplays a histogram panel 162 that displays a histogram of notableevents organized by urgency values, and a histogram of notable eventsorganized by time intervals. This key indicators view is described infurther detail in pending U.S. patent application Ser. No. 13/956,338,entitled “KEY INDICATORS VIEW”, filed on 31 Jul. 2013, and which ishereby incorporated by reference in its entirety for all purposes.

These visualizations can also include an “incident review dashboard”that enables a user to view and act on “notable events.” These notableevents can include: (1) a single event of high importance, such as anyactivity from a known web attacker; or (2) multiple events thatcollectively warrant review, such as a large number of authenticationfailures on a host followed by a successful authentication. For example,FIG. 11B illustrates an example incident review dashboard 164 thatincludes a set of incident attribute fields 166 that, for example,enables a user to specify a time range field 168 for the displayedevents. It also includes a timeline 170 that graphically illustrates thenumber of incidents that occurred in time intervals over the selectedtime range. It additionally displays an events list 172 that enables auser to view a list of all of the notable events that match the criteriain the incident attributes fields 166. To facilitate identifyingpatterns among the notable events, each notable event can be associatedwith an urgency value (e.g., low, medium, high, critical), which isindicated in the incident review dashboard. The urgency value for adetected event can be determined based on the severity of the event andthe priority of the system component associated with the event.

2.12. Data Center Monitoring

As mentioned above, the SPLUNK® ENTERPRISE platform provides variousfeatures that simplify the developers' task to create variousapplications. One such application is SPLUNK® APP FOR VMWARE® thatprovides operational visibility into granular performance metrics, logs,tasks and events, and topology from hosts, virtual machines and virtualcenters. It empowers administrators with an accurate real-time pictureof the health of the environment, proactively identifying performanceand capacity bottlenecks.

Conventional data-center-monitoring systems lack the infrastructure toeffectively store and analyze large volumes of machine-generated data,such as performance information and log data obtained from the datacenter. In conventional data-center-monitoring systems,machine-generated data is typically pre-processed prior to being stored,for example, by extracting pre-specified data items and storing them ina database to facilitate subsequent retrieval and analysis at searchtime. However, the rest of the data is not saved and is discarded duringpre-processing.

In contrast, the SPLUNK® APP FOR VMWARE® stores large volumes ofminimally processed machine data (i.e., including raw data), such asperformance information and log data, at ingestion time for laterretrieval and analysis at search time when a live performance issue isbeing investigated. In addition to data obtained from various log files,this performance-related information can include values for performancemetrics obtained through an application programming interface (API)provided as part of the vSphere Hypervisor™ system distributed byVMware, Inc. of Palo Alto, Calif.

Examples of performance metrics can include: (1) CPU-related performancemetrics; (2) disk-related performance metrics; (3) memory-relatedperformance metrics; (4) network-related performance metrics; (5)energy-usage statistics; (6) data-traffic-related performance metrics;(7) overall system availability performance metrics; (8) cluster-relatedperformance metrics; and (9) virtual machine performance statistics.Such performance metrics are described in U.S. patent application Ser.No. 14/167,316, entitled “CORRELATION FOR USER-SELECTED TIME RANGES OFVALUES FOR PERFORMANCE METRICS OF COMPONENTS IN ANINFORMATION-TECHNOLOGY ENVIRONMENT WITH LOG DATA FROM THATINFORMATION-TECHNOLOGY ENVIRONMENT”, filed on 29 Jan. 2014, and which ishereby incorporated by reference in its entirety for all purposes.

To facilitate retrieving information of interest from performance dataand log files, the SPLUNK® APP FOR VMWARE® provides pre-specifiedschemas for extracting relevant values from different types ofperformance-related event data, and also enables a user to define suchschemas.

The SPLUNK® APP FOR VMWARE® additionally provides various visualizationsto facilitate detecting and diagnosing the root cause of performanceproblems. For example, one such visualization is a “proactive monitoringtree” that enables a user to easily view and understand relationshipsamong various factors that affect the performance of a hierarchicallystructured computing system. This proactive monitoring tree enables auser to easily navigate the hierarchy by selectively expanding nodesrepresenting various entities (e.g., virtual centers or computingclusters) to view performance information for lower-level nodesassociated with lower-level entities (e.g., virtual machines or hostsystems).

Example node-expansion operations are illustrated in FIG. 11C, whereinnodes 1133 and 1134 are selectively expanded. Note that nodes 1131-1139can be displayed using different patterns or colors to representdifferent performance states, such as a critical state, a warning state,a normal state or an unknown/offline state. The ease of navigationprovided by selective expansion in combination with the associatedperformance-state information enables a user to quickly diagnose theroot cause of a performance problem. The proactive monitoring tree isdescribed in further detail in U.S. patent application Ser. No.14/253,490, entitled “PROACTIVE MONITORING TREE WITH SEVERITY STATESORTING”, filed on 15 Apr. 2014, and U.S. patent application Ser. No.14/812,948, also entitled “PROACTIVE MONITORING TREE WITH SEVERITY STATESORTING”, filed on 29 Jul. 2015, each of which is hereby incorporated byreference in its entirety for all purposes.

The SPLUNK® APP FOR VMWARE® also provides a user interface that enablesa user to select a specific time range and then view heterogeneous datacomprising events, log data, and associated performance metrics for theselected time range. For example, the screen illustrated in FIG. 11Ddisplays a listing of recent “tasks and events” and a listing of recent“log entries” for a selected time range above a performance-metric graphfor “average CPU core utilization” for the selected time range. Notethat a user is able to operate pull-down menus 174 to selectivelydisplay different performance metric graphs for the selected time range.This enables the user to correlate trends in the performance-metricgraph with corresponding event and log data to quickly determine theroot cause of a performance problem. This user interface is described inmore detail in U.S. patent application Ser. No. 14/167,316, entitled“CORRELATION FOR USER-SELECTED TIME RANGES OF VALUES FOR PERFORMANCEMETRICS OF COMPONENTS IN AN INFORMATION-TECHNOLOGY ENVIRONMENT WITH LOGDATA FROM THAT INFORMATION-TECHNOLOGY ENVIRONMENT”, filed on 29 Jan.2014, and which is hereby incorporated by reference in its entirety forall purposes.

2.13. Cloud-Based System Overview

The example data intake and query system 32 described in reference toFIG. 3 comprises several system components, including one or moreforwarders, indexers, and search heads. In some environments, a user ofa data intake and query system 32 may install and configure, oncomputing devices owned and operated by the user, one or more softwareapplications that implement some or all of these system components. Forexample, a user may install a software application on server computersowned by the user and configure each server to operate as one or more ofa forwarder, an indexer, a search head, etc. This arrangement maygenerally be referred to as an “on-premises” solution. That is, thesystem 32 is installed and operates on computing devices directlycontrolled by the user of the system. Some users may prefer anon-premises solution because it may provide a greater level of controlover the configuration of certain aspects of the system (e.g., security,privacy, standards, controls, etc.). However, other users may insteadprefer an arrangement in which the user is not directly responsible forproviding and managing the computing devices upon which variouscomponents of system 32 operate.

In one embodiment, to provide an alternative to an entirely on-premisesenvironment for system 32, one or more of the components of a dataintake and query system instead may be provided as a cloud-basedservice. In this context, a cloud-based service refers to a servicehosted by one more computing resources that are accessible to end usersover a network, for example, by using a web browser or other applicationon a client device to interface with the remote computing resources. Forexample, a service provider may provide a cloud-based data intake andquery system by managing computing resources configured to implementvarious aspects of the system (e.g., forwarders, indexers, search heads,etc.) and by providing access to the system to end users via a network.Typically, a user may pay a subscription or other fee to use such aservice. Each subscribing user of the cloud-based service may beprovided with an account that enables the user to configure a customizedcloud-based system based on the user's preferences.

FIG. 12 illustrates a block diagram of an example cloud-based dataintake and query system. Similar to the system of FIG. 4, the networkedcomputer system 176 includes input data sources 178 and forwarders 180.These input data sources 178 and forwarders 180 may be in a subscriber'sprivate computing environment. Alternatively, they might be directlymanaged by the service provider as part of the cloud service. In theexample system 176, one or more forwarders 180 and client devices 182are coupled to a cloud-based data intake and query system 184 via one ormore networks 185. Network 185 broadly represents one or more LANs,WANs, cellular networks, intranetworks, internetworks, etc., using anyof wired, wireless, terrestrial microwave, satellite links, etc., andmay include the public Internet, and is used by client devices 182 andforwarders 180 to access the system 184. Similar to the system of 32,each of the forwarders 180 may be configured to receive data from aninput source and to forward the data to other components of the system184 for further processing.

In an embodiment, a cloud-based data intake and query system 184 maycomprise a plurality of system instances 186. In general, each systeminstance 186-1 and 186-2 may include one or more computing resourcesmanaged by a provider of the cloud-based system 184 made available to aparticular subscriber. The computing resources comprising a systeminstance 186 may, for example, include one or more servers or otherdevices configured to implement one or more forwarders, indexers, searchheads, and other components of a data intake and query system, similarto system 32. As indicated above, a subscriber may use a web browser orother application of a client device 182 to access a web portal or otherinterface that enables the subscriber to configure an instance 186.

Providing a data intake and query system as described in reference tosystem 32 as a cloud-based service presents a number of challenges. Eachof the components of a system 32 (e.g., forwarders, indexers and searchheads) may at times refer to various configuration files stored locallyat each component. These configuration files typically may involve somelevel of user configuration to accommodate particular types of data auser desires to analyze and to account for other user preferences.However, in a cloud-based service context, users typically may not havedirect access to the underlying computing resources implementing thevarious system components (e.g., the computing resources comprising eachsystem instance 186) and may desire to make such configurationsindirectly, for example, using one or more web-based interfaces. Thus,the techniques and systems described herein for providing userinterfaces that enable a user to configure source type definitions areapplicable to both on-premises and cloud-based service contexts, or somecombination thereof (e.g., a hybrid system where both an on-premisesenvironment such as SPLUNK® ENTERPRISE and a cloud-based environmentsuch as SPLUNK® CLOUD are centrally visible).

2.14. Searching Externally Archived Data

FIG. 13 shows a block diagram of an example of a data intake and querysystem 188 that provides transparent search facilities for data systemsthat are external to the data intake and query system. Such facilitiesare available in the HUNK® system provided by Splunk Inc. of SanFrancisco, Calif. HUNK® represents an analytics platform that enablesbusiness and IT teams to rapidly explore, analyze, and visualize data inHadoop and NoSQL data stores.

The search head 190 of the data intake and query system receives searchrequests from one or more client devices 189 over network connections192. As discussed above, the data intake and query system 188 may residein an enterprise location, in the cloud, etc. FIG. 13 illustrates thatmultiple client devices 189-1, 189-2, . . . , 189-N may communicate withthe data intake and query system 32. The client devices 189 maycommunicate with the data intake and query system using a variety ofconnections. For example, one client device in FIG. 13 is illustrated ascommunicating over an Internet (Web) protocol, another client device isillustrated as communicating via a command line interface, and anotherclient device is illustrated as communicating via a system developer kit(SDK).

The search head 190 analyzes the received search request to identifyrequest parameters. If a search request received from one of the clientdevices 189 references an index maintained by the data intake and querysystem, then the search head 190 connects to one or more indexers 193 ofthe data intake and query system for the index referenced in the requestparameters. That is, if the request parameters of the search requestreference an index, then the search head accesses the data in the indexvia the indexer. The data intake and query system 188 may include one ormore indexers 193, depending on system access resources andrequirements. As described further below, the indexers 193 retrieve datafrom their respective local data stores 194 as specified in the searchrequest. The indexers and their respective data stores can comprise oneor more storage devices and typically reside on the same system, thoughthey may be connected via a local network connection. The data isforwarded to the indexers by forwarders 198, which obtained the datafrom data sources 199.

If the request parameters of the received search request reference anexternal data collection, which is not accessible to the indexers 193 orunder the management of the data intake and query system, then thesearch head 190 can access the external data collection through anExternal Result Provider (ERP) process 196. An external data collectionmay be referred to as a “virtual index” (plural, “virtual indices”). AnERP process provides an interface through which the search head 190 mayaccess virtual indices.

Thus, a search reference to an index of the system relates to a locallystored and managed data collection. In contrast, a search reference to avirtual index relates to an externally stored and managed datacollection, which the search head may access through one or more ERPprocesses 196-1 and 196-2. FIG. 13 shows two ERP processes 196-1 and196-2 that connect to respective remote (external) virtual indices,which are indicated as a Hadoop or another system 197-1 (e.g., AmazonS3, Amazon EMR, other Hadoop Compatible File Systems (HCFS), etc.) and arelational database management system (RDBMS) 197-2. Other virtualindices may include other file organizations and protocols, such asStructured Query Language (SQL) and the like. The ellipses between theERP processes 196-1 and 196-2 indicate optional additional ERP processesof the data intake and query system 188. An ERP process may be acomputer process that is initiated or spawned by the search head 190 andis executed by the search data intake and query system 188.Alternatively or additionally, an ERP process may be a process spawnedby the search head 190 on the same or different host system as thesearch head 190 resides.

The search head 190 may spawn a single ERP process in response tomultiple virtual indices referenced in a search request, or the searchhead may spawn different ERP processes for different virtual indices.Generally, virtual indices that share common data configurations orprotocols may share ERP processes. For example, all search queryreferences to a Hadoop file system may be processed by the same ERPprocess, if the ERP process is suitably configured. Likewise, all searchquery references to an SQL database may be processed by the same ERPprocess. In addition, the search head may provide a common ERP processfor common external data source types (e.g., a common vendor may utilizea common ERP process, even if the vendor includes different data storagesystem types, such as Hadoop and SQL). Common indexing schemes also maybe handled by common ERP processes, such as flat text files or Weblogfiles.

The search head 190 determines the number of ERP processes to beinitiated via the use of configuration parameters that are included in asearch request message. Generally, there is a one-to-many relationshipbetween an external results provider “family” and ERP processes. Thereis also a one-to-many relationship between an ERP process andcorresponding virtual indices that are referred to in a search request.For example, using RDBMS, assume two independent instances of such asystem by one vendor, such as one RDBMS for production and another RDBMSused for development. In such a situation, it is likely preferable (butoptional) to use two ERP processes to maintain the independent operationas between production and development data. Both of the ERPs, however,will belong to the same family, because the two RDBMS system types arefrom the same vendor.

The ERP processes 196-1 and 196-2 receive a search request from thesearch head 190. The search head may optimize the received searchrequest for execution at the respective external virtual index.Alternatively, the ERP process may receive a search request as a resultof analysis performed by the search head or by a different systemprocess. The ERP processes 196-1 and 196-2 can communicate with thesearch head 190 via conventional input/output routines (e.g., standardin/standard out, etc.). In this way, the ERP process receives the searchrequest from a client device such that the search request may beefficiently executed at the corresponding external virtual index.

The ERP processes 196-1 and 196-2 may be implemented as a process of thedata intake and query system. Each ERP process may be provided by thedata intake and query system, or may be provided by process orapplication providers who are independent of the data intake and querysystem. Each respective ERP process may include an interface applicationinstalled at a computer of the external result provider that ensuresproper communication between the search support system and the externalresult provider. The ERP processes 196-1 and 196-2 generate appropriatesearch requests in the protocol and syntax of the respective virtualindices 197-1 and 197-2, each of which corresponds to the search requestreceived by the search head 190. Upon receiving search results fromtheir corresponding virtual indices, the respective ERP process passesthe result to the search head 190, which may return or display theresults or a processed set of results based on the returned results tothe respective client device.

Client devices 189 may communicate with the data intake and query system188 through a network interface 192, e.g., one or more LANs, WANs,cellular networks, intranetworks, and/or internetworks using any ofwired, wireless, terrestrial microwave, satellite links, etc., and mayinclude the public Internet.

The analytics platform utilizing the External Result Provider processdescribed in more detail in U.S. Pat. No. 8,738,629, entitled “EXTERNALRESULT PROVIDED PROCESS FOR RETRIEVING DATA STORED USING A DIFFERENTCONFIGURATION OR PROTOCOL”, issued on 27 May 2014, U.S. Pat. No.8,738,587, entitled “PROCESSING A SYSTEM SEARCH REQUEST BY RETRIEVINGRESULTS FROM BOTH A NATIVE INDEX AND A VIRTUAL INDEX”, issued on 25 Jul.2013, U.S. patent application Ser. No. 14/266,832, entitled “PROCESSINGA SYSTEM SEARCH REQUEST ACROSS DISPARATE DATA COLLECTION SYSTEMS”, filedon 1 May 2014, and U.S. patent application Ser. No. 14/449,144, entitled“PROCESSING A SYSTEM SEARCH REQUEST INCLUDING EXTERNAL DATA SOURCES”,filed on 31 Jul. 2014, each of which is hereby incorporated by referencein its entirety for all purposes.

2.14.1. ERP Process Features

The ERP processes described above may include two operation modes: astreaming mode and a reporting mode. The ERP processes can operate instreaming mode only, in reporting mode only, or in both modessimultaneously. Operating in both modes simultaneously is referred to asmixed mode operation. In a mixed mode operation, the ERP at some pointcan stop providing the search head with streaming results and onlyprovide reporting results thereafter, or the search head at some pointmay start ignoring streaming results it has been using and only usereporting results thereafter.

The streaming mode returns search results in real-time, with minimalprocessing, in response to the search request. The reporting modeprovides results of a search request with processing of the searchresults prior to providing them to the requesting search head, which inturn provides results to the requesting client device. ERP operationwith such multiple modes provides greater performance flexibility withregard to report time, search latency, and resource utilization.

In a mixed mode operation, both streaming mode and reporting mode areoperating simultaneously. The streaming mode results (e.g., the raw dataobtained from the external data source) are provided to the search head,which can then process the results data (e.g., break the raw data intoevents, timestamp it, filter it, etc.) and integrate the results datawith the results data from other external data sources, and/or from datastores of the search head. The search head performs such processing andcan immediately start returning interim (streaming mode) results to theuser at the requesting client device; simultaneously, the search head iswaiting for the ERP process to process the data it is retrieving fromthe external data source as a result of the concurrently executingreporting mode.

In some instances, the ERP process initially operates in a mixed mode,such that the streaming mode operates to enable the ERP quickly toreturn interim results (e.g., some of the raw or unprocessed datanecessary to respond to a search request) to the search head, enablingthe search head to process the interim results and begin providing tothe client or search requester interim results that are responsive tothe query. Meanwhile, in this mixed mode, the ERP also operatesconcurrently in reporting mode, processing portions of raw data in amanner responsive to the search query. Upon determining that it hasresults from the reporting mode available to return to the search head,the ERP may halt processing in the mixed mode at that time (or somelater time) by stopping the return of data in streaming mode to thesearch head and switching to reporting mode only. The ERP at this pointstarts sending interim results in reporting mode to the search head,which in turn may then present this processed data responsive to thesearch request to the client or search requester. Typically the searchhead switches from using results from the ERP's streaming mode ofoperation to results from the ERP's reporting mode of operation when thehigher bandwidth results from the reporting mode outstrip the amount ofdata processed by the search head in the streaming mode of ERPoperation.

A reporting mode may have a higher bandwidth because the ERP does nothave to spend time transferring data to the search head for processingall the raw data. In addition, the ERP may optionally direct anotherprocessor to do the processing.

The streaming mode of operation does not need to be stopped to gain thehigher bandwidth benefits of a reporting mode; the search head couldsimply stop using the streaming mode results—and start using thereporting mode results—when the bandwidth of the reporting mode hascaught up with or exceeded the amount of bandwidth provided by thestreaming mode. Thus, a variety of triggers and ways to accomplish asearch head's switch from using streaming mode results to usingreporting mode results may be appreciated by one skilled in the art.

The reporting mode can involve the ERP process (or an external system)performing event breaking, time stamping, filtering of events to matchthe search query request, and calculating statistics on the results. Theuser can request particular types of data, such as if the search queryitself involves types of events, or the search request may ask forstatistics on data, such as on events that meet the search request. Ineither case, the search head understands the query language used in thereceived query request, which may be a proprietary language. Oneexemplary query language is Splunk Processing Language (SPL) developedby the assignee of the application, Splunk Inc. The search headtypically understands how to use that language to obtain data from theindexers, which store data in a format used by the SPLUNK® Enterprisesystem.

The ERP processes support the search head, as the search head is notordinarily configured to understand the format in which data is storedin external data sources such as Hadoop or SQL data systems. Rather, theERP process performs that translation from the query submitted in thesearch support system's native format (e.g., SPL if SPLUNK® ENTERPRISEis used as the search support system) to a search query request formatthat will be accepted by the corresponding external data system. Theexternal data system typically stores data in a different format fromthat of the search support system's native index format, and it utilizesa different query language (e.g., SQL or MapReduce, rather than SPL orthe like).

As noted, the ERP process can operate in the streaming mode alone. Afterthe ERP process has performed the translation of the query request andreceived raw results from the streaming mode, the search head canintegrate the returned data with any data obtained from local datasources (e.g., native to the search support system), other external datasources, and other ERP processes (if such operations were required tosatisfy the terms of the search query). An advantage of mixed modeoperation is that, in addition to streaming mode, the ERP process isalso executing concurrently in reporting mode. Thus, the ERP process(rather than the search head) is processing query results (e.g.,performing event breaking, timestamping, filtering, possibly calculatingstatistics if required to be responsive to the search query request,etc.). It should be apparent to those skilled in the art that additionaltime is needed for the ERP process to perform the processing in such aconfiguration. Therefore, the streaming mode will allow the search headto start returning interim results to the user at the client devicebefore the ERP process can complete sufficient processing to startreturning any search results. The switchover between streaming andreporting mode happens when the ERP process determines that theswitchover is appropriate, such as when the ERP process determines itcan begin returning meaningful results from its reporting mode.

The operation described above illustrates the source of operationallatency: streaming mode has low latency (immediate results) and usuallyhas relatively low bandwidth (fewer results can be returned per unit oftime). In contrast, the concurrently running reporting mode hasrelatively high latency (it performs more processing before returningany results) and usually has relatively high bandwidth (more results canbe processed per unit of time). For example, when the ERP process doesbegin returning report results, it returns more processed results thanin the streaming mode, because, e.g., statistics only need to becalculated to be responsive to the search request. That is, the ERPprocess doesn't have to take time to first return raw data to the searchhead. As noted, the ERP process could be configured to operate instreaming mode alone and return just the raw data for the search head toprocess in a way that is responsive to the search request.Alternatively, the ERP process can be configured to operate in thereporting mode only. Also, the ERP process can be configured to operatein streaming mode and reporting mode concurrently, as described, withthe ERP process stopping the transmission of streaming results to thesearch head when the concurrently running reporting mode has caught upand started providing results. The reporting mode does not require theprocessing of all raw data that is responsive to the search queryrequest before the ERP process starts returning results; rather, thereporting mode usually performs processing of chunks of events andreturns the processing results to the search head for each chunk.

For example, an ERP process can be configured to merely return thecontents of a search result file verbatim, with little or no processingof results. That way, the search head performs all processing (such asparsing byte streams into events, filtering, etc.). The ERP process canbe configured to perform additional intelligence, such as analyzing thesearch request and handling all the computation that a native searchindexer process would otherwise perform. In this way, the configured ERPprocess provides greater flexibility in features while operatingaccording to desired preferences, such as response latency and resourcerequirements.

2.14.2. IT Service Monitoring

As previously mentioned, the SPLUNK® ENTERPRISE platform providesvarious schemas, dashboards and visualizations that make it easy fordevelopers to create applications to provide additional capabilities.One such application is SPLUNK® IT SERVICE INTELLIGENCE™, which performsmonitoring and alerting operations. It also includes analytics to helpan analyst diagnose the root cause of performance problems based onlarge volumes of data stored by the SPLUNK® ENTERPRISE system ascorrelated to the various services an IT organization provides (aservice-centric view). This differs significantly from conventional ITmonitoring systems that lack the infrastructure to effectively store andanalyze large volumes of service-related event data. Traditional servicemonitoring systems typically use fixed schemas to extract data frompre-defined fields at data ingestion time, wherein the extracted data istypically stored in a relational database. This data extraction processand associated reduction in data content that occurs at data ingestiontime inevitably hampers future investigations, when all of the originaldata may be needed to determine the root cause of or contributingfactors to a service issue.

In contrast, a SPLUNK® IT SERVICE INTELLIGENCE™ system stores largevolumes of minimally-processed service-related data at ingestion timefor later retrieval and analysis at search time, to perform regularmonitoring, or to investigate a service issue. To facilitate this dataretrieval process, SPLUNK® IT SERVICE INTELLIGENCE™ enables a user todefine an IT operations infrastructure from the perspective of theservices it provides. In this service-centric approach, a service suchas corporate e-mail may be defined in terms of the entities employed toprovide the service, such as host machines and network devices. Eachentity is defined to include information for identifying all of theevent data that pertains to the entity, whether produced by the entityitself or by another machine, and considering the many various ways theentity may be identified in raw machine data (such as by a URL, an IPaddress, or machine name). The service and entity definitions canorganize event data around a service so that all of the event datapertaining to that service can be easily identified. This capabilityprovides a foundation for the implementation of Key PerformanceIndicators.

One or more Key Performance Indicators (KPIs) are defined for a servicewithin the SPLUNK® IT SERVICE INTELLIGENCE™ application. Each KPImeasures an aspect of service performance at a point in time or over aperiod of time (aspect KPIs). Each KPI is defined by a search query thatderives a KPI value from the machine data of events associated with theentities that provide the service. Information in the entity definitionsmay be used to identify the appropriate events at the time a KPI isdefined or whenever a KPI value is being determined. The KPI valuesderived over time may be stored to build a valuable repository ofcurrent and historical performance information for the service, and therepository itself may be subject to search query processing. AggregateKPIs may be defined to provide a measure of service performancecalculated from a set of service aspect KPI values; this aggregate mayeven be taken across defined timeframes and/or across multiple services.A particular service may have an aggregate KPI derived fromsubstantially all of the aspect KPIs of the service to indicate anoverall health score for the service.

SPLUNK® IT SERVICE INTELLIGENCE™ facilitates the production ofmeaningful aggregate KPIs through a system of KPI thresholds and statevalues. Different KPI definitions may produce values in differentranges, so the same value may mean something very different from one KPIdefinition to another. To address this, SPLUNK® IT SERVICE INTELLIGENCE™implements a translation of individual KPI values to a common domain of“state” values. For example, a KPI range of values may be 1-100, or50-275, while values in the state domain may be ‘critical,’ ‘warning,’‘normal,’ and ‘informational’. Thresholds associated with a particularKPI definition determine ranges of values for that KPI that correspondto the various state values. In one case, KPI values 95-100 may be setto correspond to ‘critical’ in the state domain. KPI values fromdisparate KPIs can be processed uniformly once they are translated intothe common state values using the thresholds. For example, “normal 80%of the time” can be applied across various KPIs. To provide meaningfulaggregate KPIs, a weighting value can be assigned to each KPI so thatits influence on the calculated aggregate KPI value is increased ordecreased relative to the other KPIs.

One service in an IT environment often impacts, or is impacted by,another service. SPLUNK® IT SERVICE INTELLIGENCE™ can reflect thesedependencies. For example, a dependency relationship between a corporatee-mail service and a centralized authentication service can be reflectedby recording an association between their respective servicedefinitions. The recorded associations establish a service dependencytopology that informs the data or selection options presented in a GUI,for example. (The service dependency topology is like a “map” showinghow services are connected based on their dependencies.) The servicetopology may itself be depicted in a GUI and may be interactive to allownavigation among related services.

Entity definitions in SPLUNK® IT SERVICE INTELLIGENCE™ can includeinformational fields that can serve as metadata, implied data fields, orattributed data fields for the events identified by other aspects of theentity definition. Entity definitions in SPLUNK® IT SERVICEINTELLIGENCE™ can also be created and updated by an import of tabulardata (as represented in a CSV, another delimited file, or a search queryresult set). The import may be GUI-mediated or processed using importparameters from a GUI-based import definition process. Entitydefinitions in SPLUNK® IT SERVICE INTELLIGENCE™ can also be associatedwith a service by means of a service definition rule. Processing therule results in the matching entity definitions being associated withthe service definition. The rule can be processed at creation time, andthereafter on a scheduled or on-demand basis. This allows dynamic,rule-based updates to the service definition.

During operation, SPLUNK® IT SERVICE INTELLIGENCE™ can recognizeso-called “notable events” that may indicate a service performanceproblem or other situation of interest. These notable events can berecognized by a “correlation search” specifying trigger criteria for anotable event: every time KPI values satisfy the criteria, theapplication indicates a notable event. A severity level for the notableevent may also be specified. Furthermore, when trigger criteria aresatisfied, the correlation search may additionally or alternativelycause a service ticket to be created in an IT service management (ITSM)system, such as the systems available from ServiceNow, Inc., of SantaClara, Calif.

SPLUNK® IT SERVICE INTELLIGENCE™ provides various visualizations builton its service-centric organization of event data and the KPI valuesgenerated and collected. Visualizations can be particularly useful formonitoring or investigating service performance. SPLUNK® IT SERVICEINTELLIGENCE™ provides a service monitoring interface suitable as thehome page for ongoing IT service monitoring. The interface isappropriate for settings such as desktop use or for a wall-mounteddisplay in a network operations center (NOC). The interface mayprominently display a services health section with tiles for theaggregate KPIs indicating overall health for defined services and ageneral KPI section with tiles for KPIs related to individual serviceaspects. These tiles may display KPI information in a variety of ways,such as by being colored and ordered according to factors like the KPIstate value. They also can be interactive and navigate to visualizationsof more detailed KPI information.

SPLUNK® IT SERVICE INTELLIGENCE™ provides a service-monitoring dashboardvisualization based on a user-defined template. The template can includeuser-selectable widgets of varying types and styles to display KPIinformation. The content and the appearance of widgets can responddynamically to changing KPI information. The KPI widgets can appear inconjunction with a background image, user drawing objects, or othervisual elements, that depict the IT operations environment, for example.The KPI widgets or other GUI elements can be interactive so as toprovide navigation to visualizations of more detailed KPI information.

SPLUNK® IT SERVICE INTELLIGENCE™ provides a visualization showingdetailed time-series information for multiple KPIs in parallel graphlanes. The length of each lane can correspond to a uniform time range,while the width of each lane may be automatically adjusted to fit thedisplayed KPI data. Data within each lane may be displayed in a userselectable style, such as a line, area, or bar chart. During operation auser may select a position in the time range of the graph lanes toactivate lane inspection at that point in time. Lane inspection maydisplay an indicator for the selected time across the graph lanes anddisplay the KPI value associated with that point in time for each of thegraph lanes. The visualization may also provide navigation to aninterface for defining a correlation search, using information from thevisualization to pre-populate the definition.

SPLUNK® IT SERVICE INTELLIGENCE™ provides a visualization for incidentreview showing detailed information for notable events. The incidentreview visualization may also show summary information for the notableevents over a time frame, such as an indication of the number of notableevents at each of a number of severity levels. The severity leveldisplay may be presented as a rainbow chart with the warmest colorassociated with the highest severity classification. The incident reviewvisualization may also show summary information for the notable eventsover a time frame, such as the number of notable events occurring withinsegments of the time frame. The incident review visualization maydisplay a list of notable events within the time frame ordered by anynumber of factors, such as time or severity. The selection of aparticular notable event from the list may display detailed informationabout that notable event, including an identification of the correlationsearch that generated the notable event.

SPLUNK® IT SERVICE INTELLIGENCE™ provides pre-specified schemas forextracting relevant values from the different types of service-relatedevent data. It also enables a user to define such schemas.

In some embodiments, one or more processes and/or interfaces of aSPLUNK® ENTERPRISE SYSTEM (such as a SPLUNK® IT SERVICE INTELLIGENCE™)are configured to provide a user with an efficient system to aggregate,store, and analyze metrics for example, within a SPLUNK® IT SERVICEINTELLIGENCE™ system. In some embodiments, the one or more processes areconfigured to provide metrics solutions including selective indexing ofmetrics, real-time search, a metrics catalog, ingestion protocols forstandard ingestion of data, storage of raw metrics data, search commandsand capabilities, in memory caching, conversion of log data to metricsdata during ingestion, floating point compression and timestampcompression, dedicated file formats for metric storage, and/oradditional processes and/or interfaces.

3.0. SYSTEM FOR STORING AND ANALYZING METRICS DATA

FIG. 20 is a block diagram of a system that can support storing andanalyzing metrics data according to some embodiments of the presentdisclosure. The block diagram depicts components of the system 200 asfunctionally separate. However, it will be apparent to one of ordinaryskill in the art that the components of FIG. 20 can be combined ordivided into separate software, firmware and/or hardware components.Furthermore, it will also be apparent to one of ordinary skill in theart that such components, regardless of how they are combined ordivided, can execute on the same host or multiple hosts, and themultiple hosts can be connected by one or more networks.

The system 200 includes at least a metrics ingestion component 202, ametrics catalog and search component 204 (“metrics catalog 204” or“catalog 204”), a metrics analysis component 206, a metrics sharingcomponent 208, and a metrics store component 210. Each component mayinclude one or more components discussed in greater detail below.Generally, the ingestion component 202 is communicatively coupled to themetrics store 210, to store ingested metrics data in indexes of themetrics store 210. The metrics analysis component 206 includes featuresthat enable analyzing metrics data or data related to metrics data inthe metrics store 210 and the metrics catalog 204. For example, ametrics-aware user interface (UI) may be communicatively coupled to themetrics analysis component 206. A user can input search and/or analysiscommands via the metrics-aware UI to the metrics analysis component 206,which may retrieve data from either the metrics store 210 in secondarymemory or the metrics catalog and search component 204 in primary memory(e.g., an in memory). Lastly, the metrics sharing component 208 canenable users to share the analysis results with other users.

As used herein, the term component or module may refer to software,firmware, hardware, combinations thereof, or another component that isused to effectuate a purpose, and it will typically include a computingdevice, appliance, or host having processors and software instructionsthat are stored in a storage device, such as a non-volatile memory (alsoreferred to as secondary memory) of the computing device for practicingone or more objectives. When the software instructions are executed bythe processor(s), at least a subset of the software instructions isloaded into a memory (also referred to as primary memory) by thecomputing device, wherein the computing device becomes a special purposecomputing device for practicing the objectives. When implemented on ageneral-purpose computing device, the computer program code segmentsconfigure the computing device to create specific logic circuits.

In the example of FIG. 20, each component can run on one or more nodes(e.g., hosting devices). As used herein, the term host may refer to acomputing device, a communication device, a storage device, or anyelectronic device capable of running a software component. For example,a computing device can be, but is not limited to, a laptop personalcomputer (“PC”), a desktop PC, a tablet PC, or a server machine. Astorage device can be, but is not limited to, a hard disk drive, a flashmemory drive, or any portable storage device. A communication device canbe, but is not limited to, a mobile phone.

3.1. Metrics Collection

The metrics ingestion component 202 can include a getting data in (GDI)mechanism that enables collecting metrics data from local or remotesystems over a computer network. The GDI mechanism can include differentcollection mechanisms for collecting diverse types of metric andnon-metric data from different resources. FIG. 21 is a block diagramillustrating various collection mechanisms that can transfer metric ornon-metrics data to a receiver of a data intake and query systemaccording to some embodiments of the present disclosure. In someembodiments, the receiver 212 can be an indexer or a forwarder of a dataintake and query system. In some embodiments, a metrics-aware UI 214 canbe used to configure the receiver 212, or configure any of thecollection mechanisms over a computer network.

Examples of collection mechanisms include a universal forwarder 216, aheavy forwarder 218, an HTTP event collector (HEC) 220, a StatsDcollector 222, a technical add-on 224, an HTTP API endpoint collector226, and other collection technologies 228. In some embodiments, a largescale data collector (LSDC) 230 that supports metrics can coordinate thecollection mechanisms to improve ingestion by mitigating congestion.Other technologies that can be implemented to enhance the operations ofthe metrics system 200 include IT service intelligence (ITSI) and keyperformance indicator (KPI) support for metrics, and machine learningtechniques.

In some embodiments, the collection mechanisms can be selected orenabled via the metrics-aware UI 214 displayed on a display device. Themetrics-aware UI 214 may include a list of available collectionmechanisms, data types, and other options to customize collectionsoperations by the data intake and query system. In some embodiments,these operations are presented in a user selectable format. Examples ofdata types include unstructured, semi-structured, or structured metricsdata or non-metrics data (e.g., machine-generated data) from particularsources. Examples of the other user-selectable options include acustomizable scheduler of the LSDC that can enable certain collectionmechanisms for certain types of data or resources at certain times inaccordance with a schedule. As such, a user can customize collections ofmetrics data and non-metrics data by the receiver 212 via themetrics-aware UI 214.

3.2.1 Universal Forwarder

The universal forwarder 216 may collect data securely from one or moreremote sources over a computer network and forward the collected data tothe receiver 212 of a data intake and query system for processing,storage, and analysis. For example, the universal forwarder 216 cancollect and forward application log data alone, log and metrics data, ormetrics data alone. The metrics data may include metrics collected fromvarious computing resources over one or more computer networks. Asindicated above, each metric includes a numerical value indicative of ameasured characteristic of a computing resource. A metric may becollected as structured data, semi-structured data, or unstructureddata, and forwarded to the receiver 212 for ingestion. The process foringesting and storing metrics data by the receiver 212 of the dataintake and query system is described further below.

The universal forwarder 216 can be a streamlined, dedicated component ofthe data intake and query system that contains only essential componentsneeded to forward data to the receiver 212. As such, the universalforwarder 216 may not expose a metrics-ware UI. In some embodiments, theuniversal forwarder 216 is an executable such as an instance running ona node that collects and sends data to the receiver 212 such as anindexer, another instance, or to a third-party system. In someembodiments, the universal forwarder 216 may be the best or preferredway to forward metrics data to the receiver 212. In some embodiments,the universal forwarder 216 may only collect and forward non-metricsdata (e.g., machine-generated raw data) to the receiver 212. In someembodiments, the universal forwarder 216 can only collect and forwardmetrics data (e.g., structured or semi-structured metrics data) to thereceiver 212. In some embodiments, the universal forwarder 216 can routeeither metrics data or non-metrics data to the receiver 212.

The universal forwarder 216 can be scaled to collect relatively largeamounts of data (e.g., terabytes) from relatively large amounts ofremote systems (e.g., tens of thousands) with minimal impact onperformance. However, the universal forwarder 216 may not havecapabilities to index data locally before routing the collected dataelsewhere. The universal forwarder 216 can provide a robust solution formetrics data forwarding compared to conventional network feeds. Theuniversal forwarder may include capabilities for tagging metadata (e.g.,source, source type, and host), configurable buffering, datacompression, SSL security, and use of any available network ports.Multiple universal forwarders can be used to perform functions like dataconsolidation and load balancing across forwarders.

Although the universal forwarder 216 may not be accessible by themetrics-aware UI 214 in the streamlined version, it may still beconfigured, managed, and scaled by editing configuration files or byusing a forwarder management or distributed management console (DMC)interface. Hence, a user can selectably enable the universal forwarder216 to collect and forward data from specified sources, of specifiedsource type, and of specified data type (e.g., metric or non-metricsdata).

3.2.2. Heavy Forwarder

The heavy forwarder 218 can be an entirely separate, full instance of astreamlined executable with certain features disabled. The heavyforwarder 218 has a larger footprint than the universal forwarder 216,and retains indexer capabilities, except that it lacks the ability toperform distributed searches. Much of its default functionality, such asa web interface, can be disabled, if necessary, to reduce the footprintsize on the machine on which it runs.

Unlike the universal forwarder 216, the heavy forwarder 218 can parsedata before forwarding it and can route data based on criteria such assource or type of event. The heavy forwarder 218 can index data locally,as well as forward data to another system instance. A user can enablethese capability on, which may be disabled by default. In someembodiments, the heavy forwarder 218 can search stored data, andgenerate alerts as configured by users. In some embodiments, the heavyforwarder 218 can be accessed over a computer network via themetrics-aware UI 214. As a result, a user can selectably enable theheavy forwarder 218 to collect and forward a specified data type from aspecified source of a specified source type via the metrics-aware UI214. Thus, a user can configure, manage, and scale heavy forwardersonline.

3.2.3. HTTP Event Collector

An HTTP event collector (HEC) 220 provides a fast and efficient way fordevelopers to send application log data or metrics data over HTTP orHTTPs to the receiver 212. The HEC 220 requires only a few lines of codeadded to an application, causing it to send the log and/or metrics datato the receiver 212. The HEC 220 is token-based such that hard-coding ofcredentials in the application or supporting files is not required toenable sending data. In operation, the HEC 220 can be turned on at theendpoint machine. An HEC token is generated, a POST request is createdon the client that will post data to the HEC, and the client'sauthentication header is set to include the HEC token. Then data isposted to the HEC token receiver.

The HEC 220 can support metric protocols to send metrics data over HTTPor HTTPS to various destinations such as metrics stores in the cloud,such as SPLUNK® ENTERPRISE or SPLUNK® CLOUD, in an efficient and securemanner. The HEC 220 can also take advantage of a distributed deploymentof a data intake and query system to distribute and index very largeamounts of data. Further, various kinds of data can be sent to thereceiver 212 through the HEC 220. For example, event data sent by theHEC 220 can be raw text or formatted within a JSON object. In someembodiments, one of the logging libraries of the HEC 220 canautomatically package and send data from the HEC 220 in a selectedformat. The HEC 220 also supports assigning different source types,indexes, and groups of indexers such that a user can customize where andhow data gets ingested by the data intake and query system. In someembodiments, the HEC 220 can be customized by changing its configurationfiles.

3.2.4. StatsD Collector

The StatsD collector 222 is a daemon (i.e., background process) that cancollect metrics data and forward it to the receiver 212. Unlike the HEC220, the StatsD collector 222 runs outside an application from which itcollects data, and uses UDP protocol. Hence, the StatSD collector canavoid crashing the application from which is collects data. The StatsDcollector can include a front-end proxy for a set of tools that can beused to send, collect, and/or aggregate metrics based on the StatsDprotocol. The StatsD protocol can be a simple, text-oriented protocol,which enables the StatsD collector to reliably interact with the backendcomponents independent of languages and frameworks. It can also ensurestrict isolation between the StatsD collector 222 and the rest of thecomponents of a computer system from which it collects data.

The StatsD collector 222 enables a user to invoke or utilize the toolsas well as many StatsD libraries to meet the user's needs. Specifically,applications are instrumented by developers using language-specificclient libraries. The libraries communicate with the StatsD daemon usingthe StatsD protocol, and the daemon can generate aggregate metrics, androute data to the receiver 212. More specifically, the StatsD daemon canlisten for UDP traffic from all application libraries, aggregate metricsdata over time and then flush the metrics data. In some cases, theprotocol used between the StatsD daemon and the backend of the dataintake and query system may be HTTP-based.

The StatsD collector 222 can capture different types of metrics dataincluding gauges, counters, timing summary statistics, and sets. Asindicated above, the StatsD collector 222 can also aggregate andsummarize metrics data that has been previously summarized and reportedby a StatsD collector 222. The StatsD collector 222 may create newmetrics by applying, for example, different aggregations (e.g., average,minimum, maximum, median) to multiple reported metrics (e.g., metricsdata points). In some embodiments, after metrics are collected byanother collector (e.g., the universal forwarder 216), the StatsDcollector can then aggregate the collected metrics and route theaggregated metrics to the receiver 212. The aggregated metrics may berouted on regular intervals for further processing.

3.2.5. Batch and Streaming Data Extraction

In some embodiments, metrics are extracted and logged in batchesaccording to a schedule. For example, each metric can be batched priorto being sent to the HEC 220, and then subsequently routed over anHTTP-based protocol to the receiver 212. In some embodiments, batchingcan be automatically enabled by specifying one or more batching-specificproperties, and then queue metrics to be sent to the HEC 220 accordingto those properties. For example, a token property can be a requiredproperty to use for batching, and an interval can be set to flushmetrics at specified time intervals, such as every second, when aspecific number of metrics have been queued, or when the size of queuedmetrics equals or exceeds a threshold amount. In some embodiments, thebatching can be performed manually. In some embodiments, data isextracted and streamed to create a metric of the data for subsequentanalysis.

3.2.6. Technical Add-Ons and Build Support

The technical add-ons (“add-ons”) 224 can support metrics data. Add-onscan generally import and enrich data from any source, creating a richdata set that is ready for direct analysis or use in an application. Theadd-ons 224 can also be used to extend the capabilities of a data intakeand query system. The add-ons 224 can be proprietary or open sourcetechnologies. In particular, an add-on is a reusable software componentlike an application but does not contain a navigable view. A singleadd-on can be used in multiple applications, suites, or solutions. Theadd-ons 224 can include any combination of custom configurations,scripts, data inputs, custom reports or views, and themes that canchange the look, feel, and operation of metrics ingestion.

More specifically, the add-ons 224 can help to collect, transform, andnormalize data fields from various sources. Examples of add-ons includeAmazon Web Services (AWS) CloudWatch, Containerization (e.g.,cAdvisor/Heapster), and Docker Remote API. In some embodiments, theadd-ons 224 can adopt open platform communication (OPC), which is aplatform-independent interoperability standard for secure and reliableexchange of data among diverse platforms from multiple vendors. OPC canenable seamless integration of those platforms without costly,time-consuming software development. In some embodiments, Google CloudPlatform (GCP) StackDriver Monitoring API can be adopted to collectmetrics and metadata from, for example, AWS, hosted uptime probes,application instrumentation, and a variety of application componentsincluding Cassandra, Nginx, and Apache Web Server.

The disclosed embodiments include an add-on builder (“builder”), whichis an application that helps users build and validate the add-ons 224for a deployment. The builder can guide a user through all the stepsnecessary to create an add-on, including building alert actions,adaptive response actions, etc. In some embodiments, the builder usesbest practices and naming conventions, maintains CIM compliance toreduce development and testing time while maintaining quality ofadd-ons. The builder can be used to validate and test an add-on to checkfor readiness and to identify limitations such as compatibilities anddependencies, and to maintain a consistent look and feel while stillmaking it easy to add branding.

3.2.7. HTTP API Endpoint

In some embodiments, an HTTP API endpoint collector 226 is part of amodular subsystem that allows for creating custom scripts to accessmetrics using APIs of third-party vendors to stream the metrics data tothe receiver 212.

3.2.9. Large Scale Data Collector Support for Metrics

The disclosed collections technologies may optionally include the largescale data collector (LSDC) 230 that supports metrics data. For example,the data intake and query system may include numerous modular inputmechanism to stream metrics data from different collectors over one ormore computer networks. A module input mechanism may include customscripts that can call third-party APIs to pull large volumes of metricsdata from distributed computing sources. For example, a data intake andquery system may include multiple add-ons and HECs that are operable tocollect metrics and/or non-metrics data.

The data intake and query system may experience congestion caused by themultiple data streams being communicated from multiple sources overnetworks to different modular inputs of the receiver 212. In some cases,congestion can be mitigated by using alternate routes to communicate thedata to the receiver 212. However, congestion may persist due toreceiving the multiple data streams by the same destination at the sametime.

The LSDC 230 overcomes the drawbacks caused by collecting large amountsof data (e.g., metrics or non-metrics data) from numerous differentcomputing sources over one or more networks. Specifically, the LSDC 230can be a centralized process that manages multiple modular inputs thatcan receive multiple data streams from different sources. The LSDC 230is a distributed task scheduler that can manage different APIs tocoordinate scheduling across multiple collectors for one or moreindexers, which can result in significant performance improvements. Forexample, the LSDC 230 can coordinate scheduling of various types ofcollectors such as any combination of add-ons and HECs. Thus, the LSDC230 can avoid congested links and coordinate a uniform transfer scheduleto improve utilization of available resources.

3.2.10. IT Services for Metrics Data

The disclosed embodiments include metrics data IT service intelligence(MITSI) services. MITSI services can be invoked to monitor metrics datafor service health, to perform root cause analysis, to receive alerts,and to ensure that IT operations are in compliance with businessservice-level agreements (SLAs). MITSI services enable analysts todefine services that model IT infrastructure or computing resources.

The MITSI services can perform monitoring and alerting operations andcan help an analyst diagnose the root cause of performance problemsbased on large volumes of metrics data correlated to the variousservices an IT organization provides. In particular, the MITSI servicescan store large volumes of metrics-related data at ingestion time forlater retrieval and analysis at search time, to perform regularmonitoring or to investigate a service issue. An analyst can define anIT operations infrastructure from the perspective of the services itprovides. A service can be defined in terms of entities used to providethe service, such as host machines and network devices. An entity isdefined to include information identifying all metrics data thatpertains to the entity, whether produced by the entity or anothermachine, and considering the ways that the entity may be identified bymetrics data (e.g., source name, source type, and host). The service andentity definitions can organize metrics data around a service so thatall metrics data pertaining to the service can be identified. Thiscapability enables implementing metric key performance indicators(MKPIs).

MKPIs are defined for a service within an MITSI application. Each MKPImeasures an aspect of service performance at a point in time or over aperiod of time. Each MKPI is defined by a search query that derives aMKPI value from the metrics data associated with the entities thatprovide the service. Information in the entity definitions may be usedto identify the appropriate metrics at the time a MKPI is defined orwhenever a MKPI value is determined. The MKPI values derived over timemay be stored to build a repository of current and historicalperformance information for the service, and the repository itself maybe subject to search query processing. Aggregate MKPIs may be defined toprovide a measure of service performance calculated from a set of MKPIvalues; this aggregate may be taken across defined timeframes and/ormultiple services. A service may have an aggregate MKPI derived fromsubstantially all the service's MKPIs to indicate an overall healthscore for the service.

The MITSI services can facilitate producing meaningful aggregate MKPIsbased on thresholds and state values. Different MKPI definitions mayproduce values in different ranges and, as such, the same value mayindicate something different for different MKPI definitions. Forexample, an MITSI service can translate individual MKPI values into acommon domain of “state” values such as “critical,” “warning,” “normal,”and “informational.” Thresholds set for particular MKPI definitionsdetermine ranges of values for that MKPI that correspond to variousstate values. For example, a first range of MKPI values may be set as a“critical” state in the state domain. MKPI values from disparate MKPIscan be processed uniformly once they are translated into the commonstate values using the thresholds. For example, “normal 80% of the time”can be applied across various MKPIs. To provide meaningful aggregateMKPls, a weighting value can be assigned to each MKPI so that itsinfluence on the calculated aggregate MKPI value is increased ordecreased relative to the other MKPIs.

During operation, MITSI services can recognize “notable metrics” thatmay indicate a service performance problem or other situation ofinterest. The notable metrics can be recognized by a “correlationsearch” specifying trigger criteria for a notable metric. For example,every time MKPI values satisfy a criteria, an application indicates anotable metric. A severity level for the notable metric may also bespecified. Furthermore, when trigger criteria are satisfied, acorrelation search may cause the creation of a service ticket in ametric IT service management (MITSM) system.

MITSI services can be particularly useful for monitoring orinvestigating service performance. Moreover, a metrics-aware UI caninclude interactive and navigable visualizations of MKPI information.Lastly, MITSI services can provide pre-specified schemas for extractingrelevant values from different types of service-related metrics data.The disclosed embodiments enable users to define such schemas. In someembodiments, the metrics ingestion component can adopt machine learningmethods to monitor and analyze the metrics data.

3.3. Metrics-Aware User Interface

A metrics-aware user interface (UI) (e.g., metrics-aware UI 214) is ameans by which users and a data intake and query system interact. Themetrics-aware UI can have interactive components that allow users tocustomize a deployment of the data intake and query system. Themetrics-aware UI can include controls for users to configure operationsof the data intake and query system involving a combination ofcollection mechanisms, data sources, and data types. For example, a usercan selectively enable an HEC to collect application log data from aremote source and enable a StatsD collector to collect only metrics datafrom another remote source.

The metrics-aware UI can enable users to interact with any of thecomponents of metric system 200. For example, the metrics-aware UI canenable users to interact with the metrics catalog 204, which can furtherinteract with the other components of the system 200. As such, themetrics-aware UI can provide a user with an onboarding metricsmanagement experience. As shown by the numerous illustrations discussedin greater detail below, the metrics-aware UI enables users to view,manage, add, and delete metrics-related data. For example, a user canselect multiple options and mechanisms via the metrics-aware UI such asmetrics dimensions to be collected or analyzed. In another example, themetrics-aware UI can also be used to enable or schedule ingestion timesor search times.

A user can use the metrics-aware UI to request an analysis of any numberof measures of any number or series of characteristics or dimensionvalues, based on catalog or field extraction rules defined by themetrics catalog and search component 204. In some embodiments, theoptions available via the metrics-aware UI can be configured ormonitored by another component of the data intake and query system. Insome embodiments, a user can use the metrics-aware UI to define orspecify options for metrics to be collected or analyzed. For example,the metrics-aware UI may enable users to define metric dimensions usedby collection mechanisms to collect metrics data with the user-defineddimensions. A distributed management console (DMC) separate from, orincluded in, the metrics-aware UI can monitor a variety of performanceinformation of the data intake and query system.

3.4. Metrics Ingestion

During ingestion, metrics data can be acquired over computer networksfrom remote computer systems. The metrics data can be ingested in anyformat and transformed into a multi-dimensional structure. Thetransformed metrics data may be referred to as pipelined metrics data,which typically includes numerous key values that populate thedimensions of the multi-dimensional structure. Ingestion can includetechniques for processing metrics data received via collectors byreceivers, such as indexers. The metrics data may include numerousmetrics, where each metric has at least one or only one numerical valuethat represents a measurement. The received metrics may be structureddata, semi-structured data, or unstructured data.

In some embodiments, a metric includes multiple key values and only asingle numerical value that represents the measured characteristic of acomputing resource. The numerical value can be a floating point valuewith multiple decimal place values depending on the precision of themeasurement. Examples of a characteristic of a computing resourceincludes a utilization of a processor, a temperature of an electroniccomponent, or a voltage reading of an electronic component. Unlike keyvalues, numerical values (except zero) tend to be unique among allmetrics.

In some embodiments, metrics can include any suitable measureable metricof one or more computing components. For example, a temperature metriccan include dimensions such as time, location (latitude/longitude), anda value (e.g., in degrees); a pressure metric can include dimensionssuch as time, valve IDs, and a pressure value (e.g., in psi); ITmonitoring metrics can include dimensions such as time, host, PID, andIT values such as CPU utilization or memory usage; an internal metriccan include dimensions such as time, user, and a value such as searchcount; and a web access metric can include dimensions such as requestorIP, requestor method, requestor URL, and a value such as requestduration or count. However, the embodiments are not limited to thesetypes of metrics. Instead, the metrics can include any suitableperformance measurement.

FIG. 22 illustrates an example of a metric index 240 including multiplemetrics according to some embodiments of the present disclosure. Asshown, each metric 242 can be structured as an n-tuple record includingrequired dimensions 244, optional dimensions 246, and a measure value248. Examples of the required dimensions 244 include a time dimension ora name dimension. The time dimension includes a value indicative of atime when the measure value was taken. The name dimension includes avalue indicative of a computing resource and the characteristic of thatcomputing resource that was measured to obtain the measure value. Thename dimension essentially repurposes the source field of time-indexedevents to further enable the data intake and query to interchangeablyhandle metrics and non-metrics data seamlessly. In some embodiments, auser can set a dimension as a required dimension. For example, a sourcetype dimension can be a required dimension by default or as set by auser.

Examples of the optional dimensions 246 include a host dimension, amanufacturer dimension, and a model dimension. The manufacturer andmodel dimensions are indicative of a manufacturer and a model of anelectronic device used to obtain a measure value. Other examples of theoptional dimensions 246 include geographical or relative descriptions ofsources of metrics data such as a data center dimension with values thatcan include east, west, etc. Another example of an optional dimension isan address of the computing resource from which the measurement wastaken. FIG. 22 merely shows examples of required or optional dimensions.However, the disclosed embodiments are not so limited. For example, thehost or model dimensions may be required dimensions. In another example,the time or name dimensions may be considered dimensions.

The values of a required or optional dimension can include a stringliteral having a dotted hierarchy that represents a tag or name thatprovides metadata about the metric (e.g., technology—nginx, cloudenvironment—aws, cloud region—us-east-1 a). For example, values of thename dimension can include “cpu.temperature” and “device.voltage.” Themetrics can be of different types, such as count, timing, sample, gauge,and/or sets (e.g., unique occurrences of events). The numerical values(i.e., measure values) of metrics can also be calculated values for aspecific time resolution (e.g., count of 5xx errors for the last minute,sum, mean, upper 90th, lower 10th, etc.).

The metric index 240 illustrates an example of a structure for storingmultiple metrics. The metrics ingestion component 202 can define anynumber of metric indexes for storing any number of ingested metrics. Themetric index 240 is depicted in a table format and includes referencesto metrics data including required dimensions, optional dimensions, andmeasured values. In some embodiments, the metric index may be defined toanalyze a set of metric values of interest to a user.

The metric index 240 includes a metric in each row of the table. Thedistinct metric of each row includes dimensions that are common to allthe metrics of the index and some values for some of the dimensions. Thedimension values correspond to key values included in the ingestedmetrics data. Each metric includes dimension values for each requireddimension and measured values. The metrics also include optionaldimensions, which can be defined by a user via, for example, ametrics-aware UI. In some embodiments, the user-specified dimensions mayinclude the host, manufacturer, or model of machines (e.g., servers)used at the datacenter to take measurements. The user-specifieddimensions may also include metadata.

The dimension values (i.e., metric key values) for each metric 242include time values in the first leftmost column of the metric index240, source values of the metrics in the adjacent column, someuser-defined dimension values in the third through fifth columns, andthe measurement numerical value 248 in the last rightmost column of themetric index. As indicated above, the source dimension may also bereferred to as the metric name, which is indicative of the source of themeasured value and/or the type of measured value. The optionaldimensions of the metric index are a host, manufacturer, and model,which are associated with machines used to obtain the measured values.

In the metric index 240, a first metric entry has a measured CPUtemperature value of 96.2012, at time 0 for a webserver. The webservervalue is the only optional dimension value of this metric. The nextmetric entry is a device voltage value of 0.781, at time 0 of an unknownhost, measured by a device manufactured by Samsung having a model numberAX321. The metric index includes six other metric entries having valuesfor each required dimension and measure, and some values for someoptional dimensions.

The metric index 240 also includes different series of metrics forrespective computing resources. Specifically, the metric index 240includes a device.voltage series 250 of measurements taken by differentdevices at times 0, 10, and 20. The metric index also includes acpu.temperature series of measurements of a webserver at times 0, 10,and 20. As shown, each series has time ordered values, and a particularseries has different values for optional dimensions. For example, thedevice.voltage series has different user-specified dimension values(e.g., manufacturer and model values).

Thus, the metrics can collected and routed to receivers of the dataintake and query system are ingested and processed to store instructures such as multi-dimensional metric indexes. Examples ofreceivers include indexers that receive metrics data routed fromforwarders or any other collection mechanism. Another example of areceiver is the forwarder itself, which may also have capabilities toindex metrics data. Although shown collectively in a metric index, theingested key values that are used to populate dimensions may be storedseparately or can be included in multiple indexes. For example, theingested key values of each metric may be stored separately and can becollectively displayed in one or more metric indexes. In anotherexample, the key values for each metric may be stored separately on aper key basis.

During ingestion, the pipelined metrics can be tagged with index valuesindicative of the indexes where the metrics are to be stored. An indexvalue can be used by the data intake and query system to group metricstogether into a metric index used for subsequent search and analyticsoperations. Then, during indexing, an indexer (or other receiver withindexing capabilities), such as the indexer 46 of FIG. 4, can index themetrics using similar operations that are described in connection withmachine data discussed with respect to FIG. 4.

In some embodiments, the pipelined metrics are streamed to indexprocessors, which can handle metrics in different ways. For example, foractive real-time searches, separate real-time search processes connectthe index processers to a management port, to route the metricssatisfying the real-time searches as streams from the index processorsto the management port as search results. The process for real-timesearches is described in greater detail below.

In some embodiments, the pipelined metrics can be alternatively oradditionally written to a journal structure on a disk. In someembodiments, the journal is structured as a list of metrics that can becompressed or optimized to reduce the required amount of storage. Ametric-series index (msidx) file can be populated with key-values andnumerical values of the metrics. For example, the metrics can beasynchronously batched into a msidx file for an indexer. The msidx fileis used to process subsequent historical searches. The process forperforming historical searches is described in greater detail below.

The data received by a receiver may include metrics or non-metrics dataincluding meta values indicative of a source, source type, or host fromwhich the data was obtained. As such, metrics data represents a subsetof all the types of data that can be ingested by the data intake andquery system. In some embodiments, the meta values can be used todetermine how to process the data. For example, data having differentsource types may be processed differently, and data having the samesource type may be grouped and processed the same way.

The ingested metrics data can be distinguished over non-metrics databecause metrics data has unique properties that are different from othertypes of data. For example, the source values of metrics map to metricnames indicative of a type of measurement and computing resource. Incontrast, the source values of other types of data can be merelyindicative of physical or logical structure from which the data wasobtained. Moreover, metrics can be structured or semi-structured datathat does not include raw data. In contrast, other types of data thatare processed into events include raw data. Thus, metrics may not be orinclude unstructured data or may be constrained to have certainnecessary or optional dimensions.

In operation, receivers of the data intake and query system can opennetwork ports that receive metrics data from collectors such as a StatsDcollector or a universal forwarder. As metrics stream into the openedports, rules based data extraction capabilities are used to delineatethe metrics, transform them into a specified structure, and move them tospecified locations. In some embodiments, the data intake and querysystem may include operators specifically designed to exclusivelyprocess structured metrics data, rather than using general processingtechniques that can process non-metrics and metrics data. For example,operators can be designed specifically to process StatsD data. In someembodiments, operators enable tagging ingested metrics data to improveor expand processing or search capabilities.

The received metrics data from different collectors is parsed to extractkey values mapped to the multi-dimensional data model for metricsdescribed above. For example, each time, source, source type, and hostassociated with a measured value is mapped into the dimensions of ametric. As a result, the data intake and query system can ingest verylarge volumes of data, having metrics structured in different formats,and convert all of them into the same common format described above. Theformatted metrics can then be arranged into one or more metric indexesfor subsequent processing, search, and analysis. For example, themetrics or data derived from the metrics can be catalogued forsubsequent search and analysis of metrics data and non-metrics data in auniform manner, as described in greater detail below.

FIG. 23 is a flow diagram illustrating a method for ingesting metricsdata (e.g., semi-structured data or structured metric data) according tosome embodiments of the present disclosure. The method 2300 isperformed, at least in part, by a data intake and query system. In step2302, a data intake and query system ingests collected data includingmetrics data including key values and numerical values, where eachnumerical value (e.g., floating point value) is indicative of a measuredcharacteristic of a computing resource. Examples of a characteristic ofa computing resource include a utilization of a processor, a temperatureof an electronic component, or a voltage reading of an electroniccomponent. In some embodiments, the metrics data is received by the dataintake and query system over a computer network from remote computersystems.

In some embodiments, the data intake and query system can cause thecollection of the data from different sources by using different typesof collection mechanisms. For example, a universal forwarder can beconfigured to collect the data selected from a group consisting of onlyraw data, raw data and structured metrics data, and only structuredmetrics data. In some embodiments, a heavy forwarder can be configuredto collect and locally index collected data selected from a groupconsisting of only raw data, raw data and structured metrics data, andonly structured metrics data. The universal or heavy forwarders can thenforward the collected data to the data intake and query system.

In some embodiments, a collection mechanism includes a script running ona remote computer system configured to collect the metrics data from anapplication running on the remote computer system, where the script isincluded in the application (e.g., an HEC). The data intake and querysystem then receives the metrics data over an HTTP-based connection of acomputer network.

In some embodiments, a collection mechanism includes a backgroundprocess (e.g., daemon) of a remote computer system configured to collectthe metrics data from an application running on the remote computingsystem, where the background process is independent of the application.The data intake and query system then receives the metrics data over acomputer network.

In some embodiments, the collection mechanism includes a StatsDcollector running on a remote computer system configured to collectmetrics data and/or aggregate metrics data from the remote computingsystem. The data intake and query system then receives the metrics dataand/or aggregate metrics data over a computer network.

In some embodiments, the collection mechanism is an add-on reusablesoftware component. The data intake and query system then receives thecollected metrics data over a computer network. In some embodiments, thecollection mechanism involves calling an API of a remote computer systemto send the metrics data to the data intake and query system over acomputer network.

In some embodiments, the data intake and query system can use a largescale data collector (LSDC) to coordinate the collection of data fromdifferent sources. For example, the LSDC can schedule the transfer ofthe metrics data collected by multiple collectors from multiple remotecomputer systems, and the data intake and query system can then collectthe metrics data over a computer network in accordance with theschedule.

In step 2304, the data intake and query system generates metrics fromthe metrics data, where each metric has dimensions populated with atleast some of the key values and at least one or only one of thenumerical values. Further, one of the dimensions is a name dimensionindicative of the measured characteristic and the computing resource ofthe at least one or only one numerical value.

In step 2306, the data intake and query system indexes the metrics by atleast one of the dimensions. In some embodiments, the dimensions arerequired dimensions that must have values and/or optional dimensionsthat can have values. An example of required dimensions is a timedimension including a value indicative of when a measured characteristicwas measured. Examples of optional dimensions include a host dimension,a manufacturer dimension, or a model dimension. In some embodiments, theoptional dimensions were specified by a user before or after ingestionof the metrics data. Moreover, in some embodiments, at least some of thenumerical values are indicative of a time series of measuredcharacteristics of the same computing resource.

In some embodiments, the data ingested by the data intake and querysystem can be machine-generated data. As such, in step 2308, the dataintake and query system can also generate events indexed by timestamps,where each of the events includes a respective segment of the rawmachine data.

In step 2310, the data intake and query system can receive a searchquery having criteria indicative of a queried dimension. In someembodiments, the search query is input by a user and expressed as an SPLcommand.

In step 2312, the data intake and query system can obtain search queryresults based on the queried dimension. In some embodiments, the querieddimension is a required dimension or an optional dimension.

In some embodiments, the query results may require a correlation ofmetrics data and data from the time-indexed event. As such, the dataintake and query system can extract field values from the segments ofraw data of the events based on the criteria and correlate the extractedfield values and the search query results to obtain correlation results.Lastly, in step 2314, the search results (or correlation results) ordata indicative of the search results (or correlation results) can bedisplayed on a display device.

In some embodiments, metrics can be generated from ingested time-indexedevents that include raw data. Specifically, raw data received by thedata intake and query system is processed to create events that aretime-indexed and stored as detailed above. Then, the events can befurther processed to create multi-dimensional metrics as shown in FIG.22. For example, a query applied to time-indexed events can extract keyvalues from fields of raw data included in the events. The extracted keyvalues can be used to populate dimension values and numerical values ofmetrics. Hence, the metrics created from unstructured data can have thesame multi-dimensional structure as events generated from structureddata.

Specifically, ingested raw data can be processed into metrics having ann-tuple of elements including a timestamp, a metric name, a measurednumerical value, and many other dimensions as represented in FIG. 22.For example, log data can be stored as time-indexed events and thenprocessed to extract field values used to populate metric dimensions. Insome embodiments, the extracted field values from time-indexed eventscan be incorporated into metrics that have the same format as thestructured metrics collected from remote sources. By processing thestructured metrics and/or raw data to obtain metrics having the samespecified format, resulting metrics can be correlated to obtain newinsights about, for example, the performance of computing resources.

FIG. 24 is a flow diagram illustrating a method for creating metricsdata from ingested events according to some embodiments of the presentdisclosure. The method 2400 is performed, at least in part, by a dataintake and query system. In step 2402, the data intake and query systemingests data obtained over a computer network from remote computersystems. The data can include raw data (e.g., machine-generated data)and can additionally include structured metrics data.

In some embodiments, the data is collected using different types ofcollection mechanisms running on, for example, the remote computersystems. The collected data is then forwarded to the data intake andquery system. For example, a universal forwarder running on a remotecomputer system can be configured to collect raw data and/or structuredmetrics data. In some embodiments, a heavy forwarder running on a remotecomputer system can be configured to collect and locally index thecollected data, where the collected data is raw data and/or structuredmetrics data. The universal or heavy forwarders then forward thecollected data to the data intake and query system.

In some embodiments, a collection mechanism (e.g., an HEC) includes ascript running on a remote computer system configured to collect rawdata and/or structured metrics data from an application running on theremote computer system, where the script is included in the application.The data intake and query system then receives the raw data and/orstructured metrics data over an HTTP-based connection of a computernetwork.

In some embodiments, a collection mechanism includes a backgroundprocess (e.g., daemon) of a remote computer system configured to collectraw data and/or structured metrics data from an application running onthe remote computing system, where the background process is independentof the application. The data intake and query system then receives theraw data and/or structured metrics data over a computer network.

In some embodiments, the collection mechanism includes a StatsDcollector running on a remote computer system configured to collectmetrics data and/or aggregate metrics data from the remote computingsystem. The data intake and query system then receives the metrics dataand/or aggregate metrics data over a computer network.

In some embodiments, the collection mechanism is an add-on reusablesoftware component, and the data intake and query system receives thecollected metrics data over a computer network. In some embodiments, thecollection mechanism involves calling an API of a remote computer systemto send the metrics data to the data intake and query system over acomputer network.

In some embodiments, the data intake and query system can use a largescale data collector (LSDC) to coordinate the collection of data fromdifferent sources. For example, the LSDC can schedule the transfer ofthe data collected by multiple collectors from multiple remote computersystems, and the data intake and query system can then collect the dataover a computer network in accordance with the schedule.

In step 2404, the data intake and query system generates time-indexedevents from the received raw data. In particular, each event has atimestamp and a segment of the raw data. The events can be indexed bytheir timestamps. In some embodiments, the timestamp of a time-indexedevent is derived from the raw data it contains.

In step 2406, the data intake and query system extracts field valuesfrom the raw data of the time-indexed events. The extracted field valuesinclude numerical values (e.g., floating point values), and eachnumerical value is indicative of a measured characteristic of acomputing resource. Examples of a measured characteristic of a computingresource include a utilization of a processor, a temperature of anelectronic component, or a voltage reading of an electronic component.

In step 2408, the data intake and query system generates structuredmetrics based on extracted field values of the time-indexed events. Eachstructured metric has multiple dimensions that are populated with theextracted field values, and includes at least one or only one of thenumerical values. A name (i.e., source) dimension of the multipledimensions is indicative of a measured characteristic and a computingresource of the numerical value. In some embodiments, the data intakeand query system re-purposes its processing of the source field oftime-indexed events to process the name dimension of the metrics.

In some embodiments, the dimensions are required dimensions that musthave values and/or optional dimensions that can have values. An exampleof a required dimension is a time dimension including a value indicativeof when a measured characteristic was measured. Examples of optionaldimensions include a host dimension, a manufacturer dimension, or amodel dimension. In some embodiments, the optional dimensions arespecified by a user before or after ingestion of the data. Moreover, insome embodiments, at least some of the numerical values are indicativeof a time series of measured characteristics of the same computingresource.

In step 2410, the data intake and query system indexes the structuredmetrics. For example, the structured metrics may be indexed by thevalues of their name dimensions. In some embodiments, the data intakeand query system can index both the structured metrics generated basedon the time-indexed events and any other structured metrics that havebeen structured in the multi-dimensional format described above.

In step 2412, the data intake and query system receives a search queryhaving criteria indicative of a queried dimension of the multipledimensions. For example, the search query may be input by a user andexpressed in a pipelined search language. In some embodiments, the scopeof the search query may include time-indexed events and/or metrics data.

In step 2414, the data intake and query system obtains search resultsbased on, for example, the queried dimension. In some embodiments, thesearch is performed on either or both the structured metrics generatedbased on the time-indexed evens and structured metrics received fromother sources over, for example, a computer network. In someembodiments, the search results involve performing a correlation of thesearch results from the metrics and time-indexed events other than thetime-indexed events from which the metrics were generated. Lastly, instep 2416, the search results (e.g., correlation results) or dataindicative of the search results are displayed on a display device.

The ability of the data intake and query system to process unstructured,semi-structured, and structured data improves performance andscalability over existing systems that process unstructured dataseparately from other systems that process structured data. As a result,the disclosed technology expands the capabilities of data intake andquery systems to provide insights into metrics data or non-metrics data,as well as correlations of metrics and non-metrics data to betterunderstand system performance, instabilities, and vulnerabilities.

3.5. Hash Bucketing

As an indexer indexes data, it can create a number of files thatcollectively constitute an index. The files can include tsidx or msidxand/or journal files that reside in directories referred to as buckets.An index can reside across many buckets. Buckets can contain newlyindexed data or previously indexed data. A bucket may have a time rangedefined for the data it can contain. The bucket can move through severalstages as its data ages in accordance with aging policies. The stagesmay include “hot,” “warm,” “cold,” “frozen,” and “thawed.” The agingpolicies may be index-specific.

As buckets age, they “roll” from one stage to the next. Data activelybeing indexed goes to a hot bucket, which is searchable. The hot bucket“rolls to warm” when certain conditions occur (e.g., hot bucket reachesa maximum size), and a new hot bucket is created. Warm buckets aresearchable, but are not actively written to. When other conditions occur(e.g., index reaches maximum number of warm buckets), the warm bucket“rolls to cold.” The oldest warm bucket is typically rolled to cold.After a set period, a cold bucket rolls to frozen such that it getseither archived or deleted. If the frozen bucket is archived, it canlater be thawed. Thawed buckets are searchable.

An indexer can index data across many indexes, where each index candefine a partition of the data. Each index can have its own directorieswith subdirectories that categorize buckets by stage (e.g., hot, warm,cold, thawed). The buckets are subdirectories within those directories.The paths for the hot, warm, cold, and thawed buckets may beconfigurable such that cold buckets can be stored in a separate location(e.g., in secondary memory) from hot or warm buckets (e.g., in primarymemory).

Buckets can be clustered or non-clustered. A standalone indexer createsnon-clustered buckets. An indexer that is part of an indexer clustercreates clustered buckets. A clustered bucket can have multiple copies.A naming convention used for clustered buckets can distinguish betweentypes of copies (e.g., originating or replicated). A variety of namingconventions can be used to identify a bucket, its stage, and whether itis clustered. For example, a name of a non-clustered hot bucket may havethe format “hot_v1_<localid>”, where “<localid>” is an identifier of thebucket. In another example, naming conventions for clustered buckets ina particular stage may additionally include timestamp informationindicating the age of data in a bucket, and a globally unique identifier(e.g., unique to the deployed system).

The data intake and query system may implement various policies forcreating hot buckets. The policies may limit the number of hot bucketsand/or a time range per bucket, which constrains creating hot buckets atingest time. The data intake and query system can implement heuristicsto determine the creation of hot buckets in light of these and otherconstraints. The hot buckets are created along a time dimension tofacilitate processing time based queries by avoiding the need to searchbuckets that are not part of the queries. Thus, the heuristics areimplemented at ingest time to create hot buckets, when necessary, by atime dimension.

During search time, a search head can search buckets of a number ofindexes to retrieve query results. By organizing data into one or moreindexes having one or more buckets, each spanning a certain time rangeand organized by age, the data intake and query system can searchparticular buckets while avoiding the need to search other buckets.Since queries are typically targeted at specific time ranges, havingbuckets partition by time ranges avoids the need to search buckets notincluding the specified range. For example, in some embodiments, onlyhot or warm buckets having a time range overlapping the time range ofthe search query would be searched. A search head can search severalindexers having particular indexes (i.e., partitions of data) to a hotpath (e.g., hot buckets in primary memory) and/or a cold path (e.g.,cold buckets in secondary memory).

The use of time-based buckets improves processing of time-based queries.Specifically, a data intake and query system can store non-metric datasuch as time-indexed events in buckets having limited time ranges. As aresult, the data intake and query system only needs to search certaintime-indexed events in certain time-based buckets for certain time-basedqueries. However, the nature of metrics data is such that users may seekto query for metrics along a dimension other than time. For example, ananalyst may seek to search metrics by source. As a result, searchingmetrics by source in time-based buckets can be complex and inefficientbecause metrics from the same source can be indexed in different timebuckets at index time.

To overcome these drawbacks, the disclosed embodiments include at leastone hash bucketing technique. A hash bucket is hashed-based rather thantime-based. In particular, a hash bucket is associated with a hash valuefor a primary partition key. Examples of a primary partition key caninclude a source, a source type, a host, an arbitrary key, orcombinations thereof. In some embodiments, a primary partition keyand/or combinations of primary partition keys are specified by a userbefore ingestion.

The data intake and query system can implement policies for creatinghash buckets based on primary partition keys. For example, user-selectedprimary partition keys can be added to policies used at index time tocreate hash buckets. At index time, the data intake and query system canrun a hashing algorithm to generate hash values from primary partitionkey values of data being ingested. Each hash value can define the scopeof data written to its hash bucket. Subsequently ingested data that hasthe same hash values can be written to the same hash bucket.

In some embodiments, the primary partition key can be determined beforeindex time or dynamically at index time depending on the type of databeing ingested. For example, the disclosed hash bucket techniques may beenabled only when metrics data is being ingested (e.g., as detected) orotherwise disable by default when non-metrics data is being ingested.

For example, the data intake and query system can hash a source key,rather than using a time dimension to partition buckets. Then, metricdata having the same source values can be written to the same hashbuckets. In these cases, the use of hash buckets can improve queryprocessing compared to using time buckets, when data is searched for theprimary partition key rather than the time dimension.

In some embodiments, hash buckets can be partitioned by time in additionto one or more primary partition keys. As such, multiple hash bucketswith different time range values that are associated with the sameprimary partition key value can coexist. For example, source-based hashbuckets can be limited by a time range such that metrics data from thesame source can be written to different source-based hash buckets havingdifferent time ranges. In some embodiments, however, hash bucketingtechniques are enabled only when time coherent data is being ingested.For example, metrics data may be received in real-time such that thereis a natural time coherence to the metric data. As such, partitioningbuckets by time may be unnecessary.

During index time, heuristics determine when to create new hash bucketsthat will store the data being ingested. The heuristics implement thepolicies setting the primary partition keys used for generating hashvalues of the hash buckets. In some embodiments, the heuristics can berelatively simple or complex algorithms that consider variousconstraints when determining whether to create hash buckets and/or thesize of the hash buckets. For example, the heuristics may includeconstraints by policies that limit the number of active hash buckets andsize of each hash bucket. The heuristics may consider other rules,limits, or constraints such as computing resource constraints,processing constraints, or any user specified constraints to determinewhen to create new hash buckets.

The disclosed embodiments can also include a quarantine bucket. Duringingestion, the quarantine bucket collects data having anomalous timevalues. For example, data that has a time value substantially orsignificantly greater than the median time value of data being ingestedcould be relegated to a quarantine bucket. In some embodiments, ananomalous time value may be determined relative to a preselected timevalue or preselected range of a hash bucket or expressed as a rule in atime policy. In some embodiments, the quarantine bucket does not hash ona primary partition key. As such, for example, when the primarypartition key is a source key, metrics data of different sources can bewritten to the same quarantine bucket.

During search time, a search head can search the hash buckets of anumber of indexes. By implementing a quarantine bucket, anomalous datacan be excluded from searching, which can minimize the amount of databeing searched and avoid obtaining skewed search results. In someembodiments, the quarantine bucket can also be searched at search timeto retrieve the anomalous data associated with the primary partitionkey. In some embodiments, any data retrieved from the quarantine bucketcan be tagged to distinguish that data from other search results tofacilitate understanding the relative significance of the anomalousdata.

Hash bucketing can be implemented for metrics data or non-metrics data.By organizing data into one or more indexes having one or more hashbuckets organized by age, the data intake and query system canefficiently search particular hash buckets and avoid the need to searchother hash buckets. Specifically, partitioning buckets by a primarypartition key dimension can avoid the need to search buckets that arenot relevant to search criteria. A hash bucket can be rolled from onestage to a next stage depending on whether certain conditions (e.g., ageor size of bucket) occur. Similar to hot buckets, hash buckets can besearchable and actively being written to. In some embodiments, the hashbuckets can be rolled into warm, cold, frozen, or thawed, and/orclustered in a similar manner as described above. In some embodiments,the naming conventions used for hash buckets may involve appending dataindicative of the hash values to distinguish hash buckets from non-hashbuckets.

FIG. 25 is a flow diagram illustrating a method for hash bucketingaccording to some embodiments of the present disclosure. Althoughdescribed in the context of metrics data, the method illustrated in FIG.25 can be implemented with any type of data including time-indexedevents. The method 2500 is performed, at least in part, by a data intakeand query system. In step 2502, the data intake and query system ingestsmetrics including key values and measured values. Each metric mayinclude a primary key value of a selected primary key. For example, theselected primary key may be a source key, a host key, a source type key,or any arbitrary key selected by a user. In some embodiments, theselected primary key is included in a policy defining conditions forsubsequently generating new hash buckets. In some embodiments, theprimary key is not a time key. In other words, the hash buckets may notbe partitioned in a time dimension.

In step 2504, a hash value is generated for each metric by processingeach primary key value with a hashing function. The hashing function canbe any hashing function known or not yet known to persons skilled in theart.

In step 2506, a metric can be indexed in association with an existinghash bucket having a matching hash value. In other words, a hash bucketthat has a particular hash value associated with it can receive all themetrics having the same have value. As a result, the hash buckets of thedata intake and query system can have a number of hash bucketspartitioned by hash values of primary key values of the selected primarykey. In some embodiments, the hash buckets age and can be rolled fromhot to warm, and so on, when the hash buckets satisfy aging conditions.

In some embodiments, a quarantine bucket can be used to handle anomalousmetrics. For example, in step 2508, the data intake and query system canidentify an anomalous metric including an outlier key value relative tokey values of other metrics. For example, a time value of a metric maybe several standard deviations away from time values of related metrics.The anomalous metric can be stored in the quarantine bucket along withother anomalous metrics, irrespective of the hash values of anyanomalous metrics.

In step 2510, the data intake and query system can generate a new hashbucket for a metric having a hash value that does not match an existinghash bucket. The new hash bucket can receive that metric and othermetrics that have a hash value matching the hash value of the hashbucket. In some embodiments, the new hash bucket is generated inaccordance with heuristics defining conditions that must be satisfiedbefore generating the new hash bucket. The heuristics may be based on orrelated to user policies defining when to create new hash buckets.

In some embodiments, a new hash bucket is generated even if an existinghash bucket has a matching hash value when, for example, the size of theexisting hash bucket exceeds a threshold value. In other words, a newhash bucket for the same primary source key value can be generated whenan existing hash bucket is full. In some embodiments, a new hash bucketis generated even if an existing hash bucket has a matching hash valuewhen, for example, a time value of a metric is not within a time rangeof the existing hash bucket. In other words, a hash bucket may bepartitioned by time in addition to being partitioned by a primary keyvalue. A new hash bucket may be created when a new metric having amatching hash value has a time value that is not within a designatedtime range of the matching hash bucket.

As a result, the data intake and query system can process subsequentqueries by searching hash buckets having matching hash values of primarykeys. For example, in step 2512, search results satisfying a searchquery indicative of a queried key value can be obtained by searchinghash buckets matching the hash value of the queried key value. Forexample, a search query may specify a source, and the data intake andquery system can search only through the hash buckets of that source,and avoid searching through other hash buckets that are not for thatsource.

In some embodiments, in step 2514, the data intake and query system canalso search the quarantine bucket in addition to the hash bucketsmatching the hash value of the queried key value to obtain the searchresults. Lastly, in step 2516, the search results or data indicative ofthe search results can be displayed on a display device.

3.6. Metrics Stores

The metrics store component 210 can interact with the metrics ingestioncomponent 202, the catalog and search component 204, and the metricsanalysis component 206 to store metrics data and maintain and performbackend operations on metrics data, a catalog, and search and analysisresults. In some embodiments, the metrics store component 210 includesone or more metrics stores analogous to the data stores for time-indexedevents described above with respect to FIG. 4. The metrics stores canstore metrics in accordance with the metric index data model describedabove. That is, ingested metrics can be stored in the metric index 240.

A metrics store may contain a number of metric indexes. The scope ofeach metric index may be defined by a user before ingestion of metricsdata. For example, a metric index may have a scope limited by a range oftime, a set of source types, or any dimension or data derived from adimension. The metrics indexes of the metric store can be accessed bythe system when performing queries with criteria that specifies metricsdata. Moreover, the metrics indexes can be the basis for an in memorycatalog of metadata, including data derived from the metrics, whichenables rapid lookup, extraction, and analysis of metrics data containedin the metrics indexes.

3.7. Metrics Catalog

The catalog and search component 204 can facilitate and improve searchand analysis of metrics data stored in metrics stores. Further, thecatalog is customizable to enable monitoring metrics and alerting usersof monitored metrics. For example, FIG. 26 is a block diagramillustrating a metrics catalog system operable to search and monitormetrics data according to some embodiments of the present disclosure.The cataloging system 252 includes an in-memory catalog 254 (“catalog254”) that caches a catalog including metadata related to metrics datastored in a metrics store 256. The cataloging system 252 may alsoinclude an on-disk catalog including metadata related to metrics datastored in the metrics store 256. The metadata may be selected or definedby a user via the metrics-aware UI 258. The metrics-aware UI 258 sendsuser inputs to the catalog 254 and receives outputs from the catalog254.

The user inputs may include queries submitted by a user as text input ina search field or by selecting controls or options displayed onmetrics-aware UI 258. The metrics-aware UI 258 can return the outputssuch as query results, which can be rendered in a variety of formatsincluding visualizations that reduce the cognitive burden on users tounderstand and appreciate the insights obtained via the catalog 254.Details of the metrics-aware UI 258 and related use cases are providedfurther below.

The metrics data received from numerous sources 260 can be ingested andstored in one or more metric indexes of the metrics store 256 onsecondary memory. As described above, a user can input an SPL commandinto a search field of the metric-aware UI 258 to directly access themetrics data stored in the metrics store 256, without using the catalog254. However, the catalog 254 provides at least two improvements overtechniques for directly accessing the metrics data from the metricsstore 256. First, the catalog 254 provides in memory caching to enablerapid access to metrics or metrics related data. Second, the catalog 254can store metadata to augment or enrich the metrics data contained themetrics store 256.

The catalog 254 can cache metrics data from the metric store 256 bycalling an application programming interface (API) 262 to subsequentlyprovide rapid access to the cached metrics data by reducing the need toaccess the metric store 256. The metadata stored in the catalog 254 caninclude user defined conditions (e.g., preferences, thresholds, orranges) or rules related to the metrics data of the metrics store 256such as schedule for monitoring metrics data, and/or alerts to notify auser about metrics that satisfy conditions. As such, the catalog 254provides rapid access that can enrich the user experience of the metricsstore 256, and the API 262 can be used to retrieve data from the metricsstore 256 in accordance with the metadata stored in the catalog 254.

In some embodiments, the API 262 only manages operations related to themetadata. For example, the API 262 may manage read and write operationsof metrics data (e.g., metadata) from the metrics store. Further, metricvalues can be retrieved from the metrics store by running searches inaccordance with search commands (e.g., running SPL searches with mstatssearch commands). The cataloging system 252 may first try to obtainmetadata directly from the in-memory cache; this process does not needto run a SPL-based query. However, the separate periodic process, whichupdates the on-disk metadata, may involve a SPL-based query.

In some embodiments, the cataloging system 252 may also include theon-disk catalog 255, in addition to the in-memory catalog 254. The dataincluded in the in-memory catalog 254 may be related to the dataincluded in the on-disk catalog 255. For example, the in-memory catalog254 may have least some data in common with the on-disk catalog 255. Insome embodiments, the API 262 only retrieves metadata from the in-memorycatalog 254 or the on-disk catalog 255. In some embodiments, the dataincluded in the on-disk catalog 255 can be retrieved from the metricsstore 256. In some embodiments, the metrics-aware UI 258 can run mstats(and/or other SPL commands) queries behind the scenes to retrieve metricdata from metric store 256 or the in-memory catalog 254 on the fly(e.g., for hot data, or real-time searches).

Using the on disk catalog 255 is advantageous for metadata that needs torun computationally expensive queries to get data from metrics index andconfiguration files. As such, the cataloging system 252 can storemetadata in a separate system on disk, e.g. a file, a relational DB, aNOSQL data store, etc. The in-memory and on-disk metadata can be updatedperiodically with data from a metrics index and configuration files.

The cataloged metadata may have been directly extracted from the metricsstore 256 or input via the metrics-aware UI 259 by users to customizethe functionality of the cataloging system 252. Examples of the metadataextracted from the metrics store 256 may include dimensions or measurevalues. Examples of the metadata input by users includes rules orconditions causing retrieval of metric data from the metric store orreporting of particular metrics data that satisfies user specifiedconditions. For example, the catalog 254 may enable a user to navigateall dimensions of the metrics stored in the catalog 254 and to searchacross all of the metrics data by name and/or dimension metadata storedin the catalog 254. Further, the catalog 254 can integrate the searchresults with the analysis of other data, such as log events, to answercomplex queries.

In another example, the user specified metadata may designate extractionrules for dimension values of metrics received from specified sources.The metadata input by users may also set thresholds or alerts forreporting metrics to the users that meet or exceed those thresholds. Forexample, user specified metadata may include a rule to alert a user whenthe measurement value of a named metric exceeds a threshold value. Thus,cataloging metadata enables searching for specified dimensions ofmetrics rapidly without needing to access the metric store 256 withevery search.

In some embodiments, a user can submit a query for the catalog 254 as anumber of commands expressed in SPL input to a search bar of themetrics-aware UI 258. In some cases, the SPL commands can be used toretrieve metrics data directly from the metrics store. In other cases, auser can submit a query in a non-SPL command to access data from thecatalog but not the from the metrics store. The scope of the query mayinclude metrics data and non-metrics data (e.g., time-indexed events).The catalog 254 can then determine whether to search the metrics data ornon-metrics data or both, and further decompose the query to search themetrics data catalog 254 or store 256 and/or non-metrics data stores(not shown).

The catalog 254 understands the structure of a metric, includingdimensions, time chart, and metadata and/or descriptions. As such, thecatalog 254 can integrate the search results with an analysis of themetrics data and/or non-metrics data to answer queries, such as thedimensions available for a specified metric series, what metric seriesshare a particular dimension, what logs are related to a particularmetric series, what are the units for a particular measurement,etcetera.

The cataloging system 252 may enable users to perform managementoperations on metrics data. Examples of the management operationsinclude editing and deleting metrics. In particular, the metrics-awareUI 258 can access the catalog 254 and enable a user to edit or deleteselected metrics or related data. For example, a user can editdimensions and/or dimension values of metrics. In response, the catalog254 can store metadata such as flags indicating that metrics have beenedited or deleted. Hence, the original metrics data stored in themetrics store 256 may persist despite being edited or deleted and willappear edited or deleted to users of the catalog 254. The catalog 254can also enable a user to edit and delete metrics data such asdimensions, unit of measurements, scales, and other data.

The management operations include adding metrics metadata such asdimensions, unit of measurement, scaling information, and the like. Forexample, the catalog 254 can enable users to define or specify optionaldimensions. A user-defined catalog configuration can be used to enhanceone or more of the user experience (e.g., preferred visualization widgetand configuration of widget), the type of aggregations or metricevaluation (e.g., using an evaluation command to convert bytes to GB)that can be applied to a series of measurements, or the type ofanalytics capability that can be applied (e.g., outliers, baseline,forecasting, etc.). In some embodiments, the catalog 254 can enableusers to perform a front end evaluation of the metrics and transformunits of their measurements as necessary (e.g., bytes to GB).

The catalog 254 can also enable a user to create metric metadata such asdescriptions, relationships, and hierarchies of metrics or theirparameters (e.g., dimensions or measures). For example, the catalog 254can establish relationships among metrics stored in the metrics store256. The catalog 254 can cache these relationships as metadata. A usercan then analyze the relationships among metrics data in accordance withthe cached metadata to rapidly obtain insights.

A user can designate a hierarchical structure including an arrangementsmetrics or related parameters at different hierarchical levels. Themetrics related parameters may include computing resources from whichmeasurements are obtained. Thus, a subsequent search for metrics datafrom one of these computing resources can return hierarchical metricsdata indicative of insights about the relationship among the computingresources. In some embodiments, metadata indicative of the hierarchy canbe temporarily stored in the catalog as a metric derived from othermetrics. Thus, the catalog 254 can build an expanded set of metrics datafrom the original metrics data and store the expanded metrics data forsubsequent searches and analysis.

The cataloging system 252 can have various use cases. Examples of theuse cases are illustrated further below in the context of themetrics-aware UI 258. In one case, the catalog 254 can search and returnan enumerate list of dimensions that are compatible with the givenmetric name. For example, a user may submit the metric name “cpu_user,”and the catalog may return “host” and “data center” as dimensions thatare compatible with the “cpu_user” metric name. In another case, thecatalog 254 can search and enumerate metrics that have a givendimension. For example, a user can submit the dimension “data-center,”and the catalog may return the metric names “cpu_user,”“mem_free_bytes,” and “disk_read_ops.”

In another case, the catalog 254 can search and return an enumeratedlist of given dimension values. For example, a user may submit thedimension “IP,” and the catalog 254 may return the values “10.1.2.3,”“10.1.2.4,” and “10.1.2.5.” In other cases, a user can submit a queryfor all the metrics or dimensions available for inspection by that user,and the catalog 254 may return enumerated lists of those metrics ordimensions. In another case, a user can submit search queries by anydimensions, dimension values, or metric names, and the catalog 254 canreturn metrics data that satisfies the search queries. In yet anothercase, a user can submit a metric name, and the catalog 254 may return anenumerated list of all the functions that can be used to aggregate thenamed metric.

In some embodiments, the metrics catalog 254 can implement compressiontechniques for numerical values of metrics. Examples includedelta-of-delta timestamps and XOR-based compression of the floatingpoint values to reduce storage requirements and enable storing datain-memory, reducing latency, and improving query throughput.

FIG. 27 is a flow diagram illustrating a method for cataloging metricsdata according to some embodiments of the present disclosure. Theprocess 2700 is for selecting and configuring one or more metrics from ametric catalog for one or more components of an operational environment.In step 2702, a list of metrics is displayed on an interface to a userfor selection. For example, the interface may be the metrics-aware UI258 displayed on a display device. The list of metrics can includemetrics related to one or more elements of the components of anoperational environment. In some embodiments, the list of metrics ispredefined. The metrics can include any suitable metric type, such as,for example, gauges, counters, histograms, and/or any other suitablemetric type. In some embodiments, histograms are configured as gauges.In some embodiments, a gauge metric includes any metric that has a valuethat can go up and/or down across multiple samples, and a counter metricincludes any metric that has a value that only increases across multiplesamples. Additional and/or alternative metric types can be included.

In some embodiments, each listed metric can be configured to support oneor more values per metric. For example, each metric can be limited to asingle value per metric to provide simplification of data storage(allowing easy storage of metrics data), simplification of configurationfor keys, allowing a single key to be excluded from indexing such thatall other keys can correspond to dimensions, and simplification of dataingestion, allowing a single key for input value. In some embodiments,each metric has multiple values per metric.

In an optional step 2704, a user can sort the displayed list of metricsusing one or more sorting mechanisms, such as an alphabetic sort,sorting by one or more aspects of the metrics, using a user definedsearch/sort term, and/or any other suitable sorting mechanism. In step2706, the user selects one of the metrics from the displayed list.

In step 2708, one or more tiles or charts for the selected metric aredisplayed on the display device to the user. The one or more tiles caninclude elements of the selected metric, such as, for example, generalinformation, metric measurement values, related dimensions, tags,transaction and/or other information related to the selected metric.

In step 2710, the user can edit one or more of the tiles presented atstep 2708. For example, in some embodiments, a general information tileincludes one or more aspects of the selected metrics that can be editedby a user, such as a type of the metric (e.g., gauge, raw number,percentage), a default display of the metric (e.g., line, bar), a unitof the metric (e.g., count, cycles, MB, GB), collection frequency,and/or any other aspect of the metric. For example, a user can edit thegeneral information tile to set a collection frequency at a higher/lowerfrequency than provided as a default collection frequency.

In step 2712, the selected metric is added to a set of metrics monitoredby one or more systems, such as a user dashboard of a SPLUNK® IT SERVICEINTELLIGENCE system. In some embodiments, the selected metric is addedto a user workspace, which includes a set of user-selected metrics thatare monitored by the user.

FIG. 28 is a flow diagram illustrating a method for in memory catalogingof metadata related to metrics in a metrics store according to someembodiments of the present disclosure. The method 2800 is performed, atleast in part, by a data intake and query system. The data intake andquery system can obtain metrics data locally or from remote sources. Forexample, in step 2802, metrics are received by the data intake and querysystem over a computer network from remote computer systems.

In step 2804, indexes of the metrics store are populated with thereceived metrics, where each metric can include dimension values and ameasure value. In step 2806, metadata is cataloged in an in-memorymetrics catalog. The metadata is typically, but not always, related tothe metrics in the metrics store.

In some embodiments, metadata is user specified and can indicateconditions causing the metrics catalog to automatically retrieve metricsdata from the metrics store. In another example, the user specifiedmetadata can include a threshold of a measure value for a particularmetric, or a range of a measure value, or a preferred measure value forthat metric. The metrics catalog can use these conditions to monitormetrics data in the metrics store, retrieve that metrics data forcataloging in the metrics catalog and, as such, make that monitoredmetrics data readily available for users via an in-memory system thatavoids the need to access an in disk metrics store. In another example,the metadata can define a condition causing the display of an alertabout a metric. As such, a user can be alerted when a measure value of ametric does or does not exceed a threshold value.

In some embodiments, the metrics catalog can be used to manage themetrics store. For example, a user can add, delete, or edit metrics dataof a metrics store. However, rather than actually modifying the metricsstore, metadata can be added to the metrics catalog that indicates achange to the metrics store. For example, deleting a metric of themetrics store via the metrics catalog may cause the metrics catalog tocreate and store metadata flagging that metric as being deleted withoutactually deleting the metric. The deleted metric will then appear asbeing deleted from the metrics store when using the metrics catalog,even though the metric has not been modified in the metrics store. Inanother example, metadata can indicate units (e.g., volts or millivolts)for a metric or type of metrics, which can be used to append relatedmetrics or transform the units associated with that metric or type ofmetrics via the metrics catalog. In another example, the metadata mayindicate a relationship (e.g., hierarchical relationship) betweenmetrics in the metrics store such that the metrics catalog can presentmetrics data for the related metrics automatically to provide usefulinsights quickly.

In step 2808, the data intake and query system receives a queryincluding search criteria. The query may be input by the user as an SPLcommand via a user interface. The data satisfying the search query canalready be included in the metrics catalog. For example, data retrievedor derived from the metric store can be stored in the catalog or storedin the catalog. The data retrieved or derived from the metrics store canbe obtained in accordance with a schedule such that metrics data isreadily available for access from the in-memory catalog rather thanneeding to access the metric store, which may be in disk (or some othernon-volatile memory).

For example, in step 2810, the data intake and query system can call anapplication programming interface (API) to retrieve metrics data fromthe metrics store, and the metrics data can then be cataloged in thein-memory metrics catalog. Although FIG. 28 shows metrics data beingretrieved after a search query was received, the metrics data retrievedfrom the metrics store may be retrieved beforehand, in anticipation ofthe search query. For example, the metadata in the metrics catalog mayindicate a metric or type of metric in the metrics store that should bemonitored. Metrics data of that metric can be retrieved from the metricsstored in accordance with the metadata such that a subsequent queryregarding that metric can be addressed without needing to access themetrics store.

As such, in step 2812, the search query can be evaluated by applying thesearch criteria to the metadata or metrics data of the metrics catalog,to obtain results that satisfy the search criteria. Lastly, in step2814, the results or data indicative of the results can be displayed ona user interface of a display device.

3.8. Metrics Analysis

The metrics analysis component 206 can generate a representation ofmetrics data for analysis such as one or more charts. Examples of chartsinclude line charts, area charts, and column charts. In someembodiments, the metrics analysis component 206 can add time annotationsto metrics data by overlaying discrete notable event streams onto thecharts. In some embodiments, the metrics analysis component 206 canenable a user to visually correlate data across different generatedcharts.

In some embodiments, the metrics analysis component 206 can alert a userabout possible problems with the metrics data by integrating alertingexisting capabilities of the data intake and query system and/oradditional customized alert actions specific to the metrics data. Insome embodiments, the metrics analysis component 206 can set alerts bydirectly interacting with the generated charts.

Once the metrics data has been charted, the metrics analysis component206 can analyze the data across any combination of all or part of themetrics data and machine generated data in real time. In someembodiments, the metrics analysis component 206 can perform statisticalanalyses of the metrics data based on the search results to generateadvanced analytics on, for example, allocation, distribution, andutilization of the computing resources. In some embodiments, the metricsanalysis component 206 can identify statistical outliers and/oranomalies of the metrics data based on standard deviations of the datathrough the statistical analyses. In some embodiments, the metricsanalysis component 206 can forecast upcoming trends of, for example, thecomputing resources based on the statistical analyses of metrics data.In some embodiments, the metrics analysis component 206 can furtherperform inline metric discovery from a metrics catalog of metrics datagenerated by the catalog and search module 206.

3.9. Sharing of the Metrics Analysis

The metrics sharing component 208 can utilize or extend exportcapabilities of a data intake and query system to share results of ametrics analysis with another device or another user. In someembodiments, the results of the metrics analysis include one or more ofreports, dashboards, or metrics charts generated by the metrics analysiscomponent 206 in real time. The results of the metrics analysis can beexported in any format including, for example, CSV, PDF, PNG, andemails.

In some embodiments, the metrics sharing component 208 can integrate acollaboration model that can, for example, connect people, tools,processes, and automation into a transparent workflow with an instantmessenger (IM) and push the results of the metrics analysis in the formof images to IM channels, such as web-based group chart services, e.g.,HipChat/Slack.

3.10. Examples of the Metrics-Aware User Interface

FIGS. 29 through 31 illustrate a series of user interface screens of ametric selection interface 270. In some embodiments, the metrics-awareUI 258 may include interface 270. The interface 270 is configured toenable selection of a metric as discussed above with respect to theprocess 2700. The interface 270 displays a metric catalog list 272. Themetric catalog list 272 includes one or more metrics, pertaining toarchitecture, task assignments, task-performance characteristics,resource states, and other components.

In particular, FIG. 29 illustrates a user interface screen of a metriccatalog displaying a list of selectable metric sources according to someembodiments of the present disclosure. As shown, each metric in themetric catalog 274 can be grouped by one or more key identificationoptions, such as by application 276, shared dimensions 278, host (orother system) information 280, tags 282, and/or any other suitable fieldidentification options. The applications 276, shared dimensions 278,host information 280, and tags 282 can be determined by the one or moreelements of an operational environment. The tags 282 can identifyadditional information about the metrics such as a class of application,a class of system, or a class of data structure that generates themetrics.

FIG. 30 illustrates a user interface screen of a metric catalogdisplaying a selected metric source according to some embodiments of thepresent disclosure. As shown, when a metric 284 is selected, theinterface 270 displays one or more tiles 286. Each of the tiles 286 isconfigured to display a sub-set of information associated with aselected metric. For example, in the illustrated embodiment, theinterface 270 includes a general description tile 286-1, a dimensionstile 286-2, a metrics data tile 286-3, an event mapping tile 286-4, anda tag tile 286-5. However, it should be appreciated that fewer,additional, and/or alternative tiles can be included on the interface270. The general description tiles 286-1 is configured to displaygeneral catalog information of a selected metric 284, such as adescription of the metric, a type (e.g., a numerical type such as gauge,value, percentage, aggregate value, etc.), a default visualization type(discussed in more detail below), a unit (such as a percentage, MB, GB,clock cycles, etc.), and a collection frequency. The description of themetric is configured to provide a user with a general overview of theevent and/or machine-generated data represented by the metric.

In some embodiments, one or more parameters of the general descriptiontile 286-1 can be edited by a user. For example, in the illustratedembodiment, an edit button 288 is included in the general descriptiontile 286-1 to allow editing of the information that the tile contains. Auser can customize the general information of the selected metric 284based on individual and/or system preferences. For example, a user mayedit a description of the metric 284, change the type (e.g., change froma gauge to a percentage or other data type), change the defaultvisualization (e.g., line, circle, bar, pie, etc.), change the unit ofthe metric 284 (e.g., percentage, MB, GB, etc.), change the collectionfrequency of the metric 284, and/or any other suitable element of themetric 284.

In some embodiments, changes made to the general information of themetric 284 change how the machine-generated data and/or eventsassociated with the metric 284 are processed. For example, in someembodiments, a user can change the collection frequency of a metric 284using the interface 270. When a user changes the collection frequency ofa metric, one or more indexers can be adjusted to increase and/ordecrease a storage rate of the associated with machine-generated data.In some embodiments, a search query and/or processing rate of anassociated event can be adjusted.

In some embodiments, the value or measurement of the metric 284 can haveone or more types, such as a count, a timing, a sample, a gauge, sets,and/or can be calculated for a specific time resolution, such as thenumber of events within a given time period (e.g., count of 5xx errorsfor the last minute), sum, mean, percentiles (e.g., upper 90th, lower10th, etc.), and/or any other suitable value. In some embodiments, thevalue or measurement of the metric is automatically derived from one ormore events, as previously discussed.

In some embodiments, the interface 270 includes a dimensions tile 286-2.The dimensions tile 286-2 includes one or more dimensions (i.e.,attributes) of the metric 284. For example, as shown in FIG. 28, theselected metric 284 can include dimensions, such as server/hostinformation, cluster information, instance information, applicationinformation, and/or any other suitable dimension. The dimensions can bedefined by the metric catalog, the SPLUNK® ENTERPRISE system, by a user,and/or by a component.

In some embodiments, the interface 270 includes a metrics data tile286-3. The metrics data tile 286-3 is configured to display themachine-generated numerical metrics data of the selected metric 284. Thenumerical metrics data can be displayed in any suitable visualization290, such as, for example, as a data graph (line graph, bar graph,scatter plot, etc.), in numeric form, and/or in any other suitablevisualization. In some embodiments, the visualization 290 of the metric284 is defined in the general information tile 286-1, for example, asthe default visualization. In some embodiments, the metrics data tile286-3 is configured to display the visualization 290 over apredetermined time period. In some embodiments, a user can adjust thepredetermined time period, for example, to increase/decrease ahistorical time period and/or view a metric in real-time.

The metrics data tile 286-3 can be configured to allow additionalanalysis of a selected metric 284, such as through an analysis button292. Metric analysis is discussed in more detail further below withrespect to FIGS. 34 through 43.

In some embodiments, the interface 270 includes an event mapping tile286-4. The event mapping tile 286-4 illustrates one or more events thatare mapped and/or associated with the metric 284. The mapped events caninclude one or more events processed to generate the numeric metricsdata of the metric 284.

In some embodiments, the mapped events can include one or more userselected events. For example, the numerical metrics data of the metric284 can be provided directly and is not derived from a specific eventand/or log. However, the metrics data 284 may correlate and/or beaffected by one or more other events. The user can map one or moreselected events to the metric 284.

In some embodiments, the interface 270 includes a tags tile 286-5. Thetags tile 286-5 can display one or more tags associated with theselected metric 284. As discussed above, the tags provide additionalinformation about the metric 284, such as an associated class ofapplication, a class of system, or a class of data structure, etc.Although specific embodiments of tiles 286 are discussed herein, it willbe appreciated that the interface 270 can include fewer, additional,and/or alternative tiles.

FIG. 31 illustrates a user interface screen of a metric catalogdisplaying filtering and/or searching of metrics according to someembodiments of the present disclosure. In some embodiments, theinterface 270 can provide filtering and/or searching of metrics storedin the metric catalog. As shown, the interface 270 includes a search bar294 configured to receive a search string. The metric store or catalogis searched for one or more metrics 276, dimensions 278, hosts 280, tags282, and/or other parameters that match the search string. For example,the search string “web” is entered into the search bar 294. In response,the metric catalog is filtered for entries including the term “web.” Inthe illustrated embodiment, a revised metrics list 296 of matchingsearch results is displayed including four identified tags 298 thatinclude the term “web.”

In some embodiments, selecting a search result from the list 296, suchas tag 298-1, displays a metric listing 300 including one or more metricgroups (such as applications 302) each having at least one metric taggedwith the selected tag 298-1. In some embodiments, a user can select oneor more metrics from the metric listing 272 for customization and/orinclusion in a user dashboard.

FIG. 32 illustrates a user interface screen of a data ingestioninterface according to some embodiments of the present disclosure. Asshown, selection interface 304 is configured to allow a user to selectone or more metrics 306 of interest from the metric catalog. Inparticular, the selection interface 304 displays a list ofuser-selectable performance categories 308. Each of the user-selectableperformance categories 308 includes the user selectable metrics 306. Insome embodiments, the displayed metrics 306 can be selected by a userfor inclusion in a user-defined list of metrics. In some embodiments,selection of one or more of the displayed metrics 306 initiatesingestion and monitoring of the metric values associated with theselected metrics 306.

In some embodiments, metrics data for the selected metrics 306 isautomatically ingested. For example, each of the displayed metrics 306can be stored in the metrics catalog and each have a default type, unit,collection frequency, and metrics data source defined in the metriccatalog. When a user selects one or more of the metrics 306, the metricsdata is collected and/or ingested from one or more default sources atthe default collection interval as defined in the metric catalog. Asdiscussed above, a user can change the default collection frequency,type, unit, etc. of the selected metrics 306.

The interface 304 includes selectable collection mechanisms 310. A files& directories collection mechanism 310-1 can be selected to upload afile, index a locale file, or monitor an entire directory. An HEC eventcollector 310-2 can be selected to configure tokens that client can useto send metrics data over HTTP or HTTPs. A TCP/UP mechanism 310-3 can beselected to configure the data intake and query system to listen on anetwork port. A scripts mechanism 310-4 can be selected to obtain datafrom an API, service, or database with a script. Lastly, a distributedmanagement console monitoring 310-5 can be selected for monitoringperformance and licensing metrics collected to optimize deployment ofthe data intake and query system.

As discussed above, pre-aggregation of metrics data can occur before orduring data ingestion. For example, ingested data may be pre-aggregatedinto predefined aggregate time windows to reduce the quantity of datarequired to be ingested and/or searched. In some embodiments,aggregation is relegated to a data collector (e.g., modular input, etc.)or to a later summary indexing. In some embodiments, pre-aggregationoccurs prior to receiving the data. As indicated above, metrics can bepre-aggregated using a StatsD collector or other mechanism prior tostoring the data. In some embodiments, one or more metrics values can bestored for one or more metrics. For example, pre-aggregated metrics canbe stored with a sum, count, mean, median, min, max, and upper 95thpercentile value. An example of data aggregation is provided in TABLE 1.

TABLE 1 Servers 10 Metrics 10 Aggregations 7 Total Samples Per Day86400/10 = 8640 Total Daily Events 6,048,000 Days Tracked 30 TotalEvents 181,440,000 Average Event Size 73 bytes Daily (raw) Index Volume420 MB Daily Compressed Volume 35 MB Total (Original) Compressed Volume1050 MB Compressed journal.gz 3422 (with indexed extractions) TotalIndex Size 15 GB

As shown above, aggregating data in ten second buckets enables storageof significantly less data and reduces the total cost of operations(TCO) for metrics classes of data while providing sufficient coverage toanalyze and query the metrics data. In some embodiments, one or morealternative protocols, such as Graphite and/or InfluxDB are configuredto further reduce the storage requirements.

In some embodiments, the performance of querying data can be increasedusing indexed extractions, using indexed extractions on pre-aggregateddatasets, using report acceleration to aggregate a raw dataset, andquerying of one or more systems (such as Whisper) from Graphite as areference metrics store. In some embodiments, Whisper allows the user tolose granularity over time and has a built in data management function.The number of samples compared will not be an exact match (and in somecases, the oldest bucket for all data has a granularity of 10 m).

For example, in some embodiments, the total difference from an originalstorage of every measurement (183 GB) vs a storage of pre-aggregateddata using, for example, Graphite (784 MB), can be significant. Assumingsimilar levels of granularity, the aggregated dataset in a data intakeand query system is about 182.5 GB for one-year of data versus 784 MBfor Graphite, providing about 238 times more data in the data intake andquery system.

In some embodiments, the metrics stored in the metric store include oneor more data models. For example, in some embodiments, one or moremetrics are defined as time series metrics. Time series metrics includea metric schema and a metric time series. Metric schema include a metricname and dimension tags K and the metric time series includes atimestamp and a measure. In some embodiments, a metric time seriesincludes a series of timestamp/value tuples for a specific tuple of adimension value. For example, CPU statistics for a predetermined numberof hosts can be collected every minute such that each host's stream ofper-minute timestamp/CPU pairs constitutes a single metric time series.

In some embodiments, gauge style metrics and counter style metrics aretreated differently. For example, TABLE 2 illustrates a number ofsufficient statistics that can be tracked for every time bucket in ametric series to generate one of a gauge style metric and/or a counterstyle metric. In TABLE 2, “FP” stands for “fencepost” calculation.

TABLE 2 Aggregation Gauge Gauge (FP) Counter Counter (FP) count countaccum (count) count accum(count) sum sum accum(sum) earliest(value),value latest(value) avg count, accum(count), count, accum(count), sumaccum(sum) earliest(value), value latest(value) std/var count,accum(count), count, accum(count), sum, accum(sum), earliest(value),value, sum accum(sumsq) latest(value), accum(sumsq(delta sqsumsq(delta(value)) (value))) min/max min, N/A min(delta(value)), N/Amax max(delta(value)) median/per cXX digest N/A digest(delta(value)) N/A(approx) dc sparklines

As described further below, queries of metrics data can be sped up usingvarious techniques. For example, a metric-series index (msidx) file canbe built at index time from metrics data and then scanned at search timeto avoid searching each metric in a metrics store. In some embodiments,the msidx file can store an array of all the numerical values ofingested metrics in a predetermine area. For every metric that ismonitored/received, an entry can be written in the msidx file accordingto one or more standards, where entries can be recorded in one or moreareas, such as a source array, source type array, host array, deletearray, meta array, and a lexicon including a combination of key values.A search head can scan the msidx file to search one or more metrics,dimensions, and/or other elements stored for each metric withoutsearching each metric. In some embodiments, the search retrieval processleverages the tsats code that provides basic functionality to aggregatevalues and split by various dimensions.

In some embodiments, metric data ingestion can occur through one or moredefined collectors (i.e., collection mechanism) as described above. Forsome collectors, like a StatsD collector, dimensions can be encoded inthe metric name (source). For example, metric data can be collected fora variable collectd.cpu_idle.splunk-idx-01.west-dc.America with asource-type statsd. The variable can be transformed according to, forexample, the following process:

props.conf: [statsd] TRANSFORMS-extract dims - extract_host, extract de,extract region, extract name transforms.conf: [extract_host] SOURCE_KEY= MetaData:Source REGEX = {circumflex over ( )}(?:[{circumflex over( )}.]{1,}.) {2} ([{circumflex over ( )}.]{1,}) FORMAT= host::$1DEST_KEY = MetaData:Host [extract_dc] SOURCE_KEY= MetaData:Source REG EX= {circumflex over ( )}(?:[{circumflex over ( )}.]{1,}.) {3}([{circumflex over ( )}.]{1,}) FORMAT = dc:: $1 WRITE_META = true[extract_region] SOURCE KEY = MetaData:Source REGEX = {circumflex over( )}(?:[{circumflex over ( )}.]{1,}.) {4} ([{circumflex over ( )}.]{1,})FORMAT = region: :$1 WRITE_META = true [extract_name] SOURCE_KEY =MetaData:Source REG EX = {circumflex over ( )}(?:[{circumflex over( )}.]{1,}.) {1} ([{circumflex over ( )}.]{1,}) FORMAT = source::$1DEST_KEY = MetaData:Source

FIG. 33 illustrates a user interface screen for searching and selectingvarious types of data including metrics according to some embodiments ofthe present disclosure. As shown, the search interface 312 can allow auser to search for one or more metrics 314 for selection from, forexample, a metrics catalog. The search interface 312 includes a searchbar 316. The search bar 316 can receive a search string. The searchinterface 312 displays search results 318 corresponding to the searchstring entered by a user into the search bar 316. In some embodiments,the search results 318 include one or more logs, metrics, value,categories, dimensions, or datasets that match the search term. A usercan select a metric directly and/or can select a log, dataset, or otherresult to see one or more metrics associated with the selected result.In some embodiments, the search interface 312 includes a searchsuggestion block 320 that can display previous and/or suggested searchterms.

In some embodiments, the metric store search is a constrained use caseof the general tstats search command (e.g., a general search by thesearch head as described above), referred to mstats. The mstats searchprovides a constrained search interface for performance events withinthe metric store. In some embodiments, the mstats command comprisessyntax similar to a tstats command, such as, for example:

 I mstats [prestats=<bool>] [append=<bool>] [chunk_size=<unsigned int>]<stats-func>...FROM <index I *> [WHERE <search-query>] [BY <field-list>[span=<timespan>]]

In some embodiments, the mstats operator may access one or more systemfiles, such as a config system, to identify metric type of “hits” (e.g.,counter, gauge, etc.) and can adjust the internal search logic accordingto the metric type.

FIG. 34 is a flow diagram illustrating a method for analyzing one ormore metrics selected from a user interface. In step 3402 of the method3400, multiple metrics are provided to a user on a display of a displaydevice. As discussed above, each metric can be associated with one ormore machine generated data, such as data extracted from one or moreevents. In some embodiments, the metrics are provided to the user inresponse to one or more user search requests. In other embodiments,metrics are displayed on a user dashboard. In step 3404, the userselects one metrics.

In step 3406, multiple dimensions related to the selected metric can beprovided to the user on the display of the display device. Thedimensions can include any suitable dimension associated with themetric, such as, for example, server information, source information,metric status, metric agent/ownership, and/or any other suitabledimensions. In step 3408, the user selects one or more of the displayeddimensions.

In step 3410, the metrics associated with the selected metric name arefiltered to form a filtered metrics data set based on the selecteddimension. For example, the metrics associated with the selected metricname can be filtered to include only those metrics corresponding to oneor more of the selected dimensions, such as metric values for one ormore selected servers or other components.

In step 3412, the set of filtered metrics data is provided in avisualization. The filtered metrics data set includes metric values thatcorrespond to the one or more selected dimensions. The time period canbe based on the selected dimensions, such as, for example, selecting adefault time window associated with a selected dimension. In someembodiments, the time period is a default time period defined for theselected metric. Each metric value is associated with an instance intime that data is collected within the time period.

In some embodiments, a user can select one or more additional metricsfor analysis. In step 3414, another metric name can be selected from themetric catalog. The subsequent metric can include a metric related tothe earlier selected metric, one or more of the selected dimensions,and/or an unrelated metric. In step 3416, a set of metric values (filterand/or unfiltered) of the subsequent metric are displayed with thefiltered metrics data set of the earlier selected metric. The values foreach of the two metrics can be displayed on the same graph and/or onseparate graphs.

In some embodiments, a user can select one or more events to include inan analysis. For example, in step 3418, multiple events can be providedto a user on a display device for selection by the user. The events canbe presented as a list superimposed on the visualization of the selectedmetrics. In some embodiments, the events include one or more events thatare processed to generate the metric values of one or more of theselected metrics.

In step 3420, a visualization of the selected events is provided withthe visualization of the metrics. In some embodiments, a visualizationof the selected events is overlaid on the visualization of the selectedmetric. In step 3422, a user selects one or more of the metric values ofthe metric. In step 3424, log data for a selected event corresponding tothe selected metric value is displayed. In some embodiments, the logdata is displayed in a different graphical user interface position thanthe metrics.

In some embodiments, the method 3400 is initiated by a user selection toanalyze one or more metrics, such as, for example, selecting theanalysis button 292 of the interface 270 discussed above. In otherembodiments, the process 3400 is automatically initiated, for example,by a user dashboard or other interface configured to automaticallyprovide analysis of one or more metrics to a user.

The method 3400 provides efficient aggregation, storage, and analysis ofmetrics. The method 3400 can provide stream-process time-series metricsto one or more user interfaces, as discussed in more detail below. Insome embodiments, the method 3400 can organize and present metrics datato allow a user to deal with voluminous metrics data, automaticallycorrelate various dimensions and/or numerical measure dimensions in themetrics, and/or to lower latency and provide higher search concurrencyrequirements.

FIGS. 35 through 43 illustrate a series of user interface screens of ananalysis interface. A selection interface screen 322 includes a metriclist 324 including multiple metrics that can be selected by the user. Insome embodiments, the selectable metrics are grouped in one or moregroups, such as, for example, by application groups. A user can selectone or more of the displayed metrics for further analysis and/orviewing.

In some embodiments, the metric list 324 can be sorted by one or moreselected parameters, such as, for example, user defined metrics 326-1,application defined metrics 326-2, one or more dimension terms, and/orany other suitable sorting parameters. In some embodiments. the one ormore dimensions can be entered into a search bar 328 as a search string.Dimensions matching the entered search string are displayed in a listfor user selection. In other embodiments, the search bar 328 is replacedwith a drop-down menu, radio buttons, and/or any other suitableselection interface.

In some embodiments, when the metric 330 is selected, the interface 322displays one or more charts or tiles 332 associated with the selectedmetric 330. The tiles 332 can include a general information tile 332-1,a dimensions tile 332-2, a metrics data tile 332-3, and/or any othersuitable information tile. The general information tile 332-1 is similarto the general information tile 286-1, the dimensions tile 332-2 issimilar to the dimensions tile 286-2 and the metrics data tile 332-3 issimilar to the metrics data tile 286-3 discussed above and, as such,similar descriptions are not repeated herein.

In some embodiments, the analysis interface 322 is configured fordetailed analysis of one or more selected metrics in the metric list324. In the illustrated embodiment, the metrics data tile 332-3 includesa selectable analyze option, such as an analyze button 334, forgenerating one or more additional interfaces configured to providedetail analysis of the selected metric 330.

When analysis of a selected metric is initiated (for example, by userselection of the analyze button 334), an investigation interface 322 isdisplayed including a metrics data tile 336 for the selected metric 338,as shown in FIG. 36. One or more dimensions associated with the selectedmetric 338 are displayed for user selection. For example, in theillustrated embodiment, a list 340 of five dimensions associated withthe selected metric 338 is displayed.

When one or more of the associated dimensions of the list 340 areselected, the metrics data (e.g., metric values) associated with theselected metric 338 is filtered to form filtered metrics data, as shownin FIG. 37. A filtered data set tile 342 is displayed including afiltered metric visualization 344. In some embodiments, the selecteddimension includes one or more additional sub-dimensions 346 that can beselected by a user to further filter the metrics data. For example, inthe illustrated embodiment, the selected dimension 348 “server_name” hasten sub-dimension options 346 (i.e., the names of ten servers aredisplayed). The first four of the sub-dimension options have beenselected by a user to filter the metrics data of the selected metric338. Four metric visualizations 344 are displayed corresponding to thefour selected servers.

In some embodiments, the filtered metric visualization 344 includes anx-axis defining a time period including a plurality of values in themetrics data associated with an instance in time that data is collected.For example, in the illustrated embodiment, the filtered metrics data isdisplayed over a plurality of minutes, with each minute including aplurality of transaction count values (the selected metric 338)associated with an instance in time (e.g., a second) that the metricsdata is collected. Although a specific embodiment is illustrated, itwill be appreciated that any suitable time period can be defined for thefiltered metrics data based on the selected dimensions. FIG. 38illustrates a search interface 350 including a search bar 352 configuredto allow a user to search for metrics 354. The user can select one ormore metrics 354 for detailed analysis.

As shown in FIG. 39, in some embodiments, multiple metrics 356 can bedisplayed on the interface 322. In some embodiments, the display of afirst metrics data block 358-1 and a second metrics data block 358-2 areadjusted to scale one or more axes (such as a time axis or a value axis)to display corresponding values for the respective selected metrics356-1 and 356-2.

For example, in some embodiments, a first metric 356-1 and a secondmetric 356-2 are selected by a user using the interface 322. The firstmetric 356-1 has a first plurality of metric values associatedtherewith, each corresponding to a measurement of the metric 356-1 at aninstance of time that the data is collected. The first metric 356-1 hasa first collection frequency. The second metric 356-2 has a secondplurality of metric values associated therewith, each corresponding to ameasurement of the metric 356-2 at an instance in time the data iscollected. The second metric 356-2 has a second collection frequency.The first collection frequency and the second collection frequency canbe different.

When only one of the first and second metrics 356-1 and 356-2 areselected for display, the selected metric 356-1 or 356-2 can bedisplayed with a time axis derived from the collection frequency thereofand a default time range of interest. When two or more metrics 356-1 and356-2 are selected for simultaneous display, the time axis and/ordefault time range of the selected metrics 356-1 and 356-2 is adjustedsuch that each selected metric 356-1 and 356-2 is displayed in anoverlapping time frame.

Although embodiments are discussed herein with overlapping time axes, itwill be appreciated that the first metric 356-1 with the second metric356-2 can be displayed with non-overlapping time ranges. For example, insome embodiments, the second metric 356-2 may be related to the firstmetric 356-1 at some time delay X, such that a first metric 356-1 valueat time t0 correlates to a second metric 356-2 value at time t0+X.

FIGS. 40 through 43 illustrate an investigation interface 360 configuredto display a plurality of metric values and a plurality of log valuesassociated with a selected metric. As shown in FIG. 40, a user cansearch for one or more logs. For example, in some embodiments, a usercan enter one or more search terms into the search bar 362. A list 364of logs that match the one or more search terms is displayed. A user canselect one or more of the displayed search terms.

FIG. 41 illustrates one embodiment of the interface 360 includingdisplayed log data 366 corresponding to metric values for a selectedmetric 368. In some embodiments, the log data includes a listing of logevents that can be displayed when a user hovers and/or otherwiseinteracts with the displayed log data 366. As shown in FIGS. 42 and 43,the log data can be displayed with and/or correlated with two or moreselected metrics 370. In some embodiments, as shown in FIG. 43, theselected metrics 372, 374 and/or log data 376 can be added to a userdashboard.

FIGS. 44 through 56 illustrate one embodiment of a user dashboard andmethod for further investigation of one or more selected metrics. FIG.44 illustrates a user dashboard 378 having a plurality of metric charts380 displaying the status of multiple metrics. The metrics can beselected by a user (for example, according to the analysis process 3400discussed above), automatically selected by a SPLUNK® ENTERPRISE system,and/or selected by one or more additional users and/or systemcomponents. In some embodiments, the user dashboard 378 can be used toaddress one or more service scenarios to identify and resolve serviceissues within an operational environment.

In some embodiments, the user dashboard 378 is configured to monitor theone or more metric charts 380 to identify notable events, such asservice anomalies, forecast changes, and/or other notable events. If anotable event is detected, the SPLUNK® ENTERPRISE system can generate ane-mail, chat message, or other communication to notify a user associatedwith the user dashboard of the notable event. In some embodiments, thecommunication includes a link to an investigative window, such as theinvestigation interface 380 illustrated in FIG. 47. In otherembodiments, the user can search for one or more metrics identified withnotable events. For example, as shown in FIGS. 45 and 46, a search bar382 is included in the user dashboard 378. A user can enter a metricdimension, such as a metric name, in the search bar 382. In someembodiments, the search results are configured to highlight one or moremetrics 384 with one or more notable events.

In some embodiments, one or more indicators 386 are overlaid on themetric chart 388 for the selected metric. The one or more indicators 386identified one or more time periods corresponding to notable events ofthe selected metric. In the illustrated embodiment, the indicators 386-1and 386-2 include dots, but it will be appreciated that the indicatorscan include any suitable indicator, such as a line, dot, arrow, and/orother indicator. In some embodiments, the metric visualization 388 caninclude additional information, such as, for example, a baselinevisualization (not shown) overlaid on the chart to identify the typicaltrends corresponding to the time of day for the anomalies.

In some embodiments, the user dashboard 378 is configured to allow auser to filter the metrics data corresponding to the metric chart 388.For example, in some embodiments, the search bar 382 is configured toreceive one or more dimensions. As discussed above with respect toprocess 3400, one or more dimensions can be selected to filter metricvalues of a selected metric. FIG. 50 illustrates the user dashboard 378having a metric sorted by application. In some embodiment, sorting themetric by application (or other dimension) allows a user to quicklyunderstand whether the anomaly is consistent across an entire platform(e.g., across all servers) or is an instance specific problem.

In some embodiments, one or more additional metrics can be selected andadded to the user dashboard 378 to allow a user to understand how anenvironment has changed that may affect performance. In someembodiments, additional metrics are added over a common time window tobe compared against the currently displayed metric 388 and/or added fora historical time window (such as yesterday/last week/last month). Eachof the additional metrics and/or time windows can be added to the samewindow on the user dashboard 378. In some embodiments, a user may selectone or more related metrics, such as available server counts, counts oftransactions sent and responded to by each server, OS resource usage(e.g., CPU, Memory, Disk I/O, Network I/O) for each server,ingress/egress traffic and/or connections from each component, count ofsuccessful verse failed transactions by a server, and/or any othersuitable related metrics. FIG. 51 illustrates a first metric 390-1correlated with a second metric 390-2.

In some embodiments, the user dashboard 378 can allow a user to quicklyvisualize metric trends for one or more metrics for any selected timewindow, including historical and/or current time windows. In someembodiments, the metrics are presented such that a user can exploremillions of time series data points from multiple data sources (such asREST API, Pub/Sub Subscriptions, JMX monitoring, scripted inputs, OSSAgents via TCP/UDP, etc.) and provide a quick time to value whengenerating visualization for a selected metric.

As discussed above, in some embodiments, the selected metrics 390-1 and390-2 can have multiple collection frequencies and/or time resolutions(e.g., 15 seconds, 30 seconds, 1 minute, 5 minutes, etc.) depending onthe technology and/or software component monitored, which can result ina different number of data points for the same time window for two ormore metrics 390-1 and 390-2.

In some embodiments, one or more events can be overlaid on a firstmetric 2202 i and correlated with the plurality of metric values of thefirst metric. For example, as shown in FIGS. 52 through 55, in someembodiments, a user dashboard 378 can include an overlay options box 392configured to allow a user to overlay events corresponding to the metricvalues of the first metric 390-1. FIG. 54 illustrates an eventvisualization 394 (shown as a bar graph) overlaid on the first metricvisualization 390-1. In some embodiments, a portion of the eventsvisualization 394 and/or the first metric visualization 390-1 can beselected by a user to display log data associated with the selectedevents 396.

For example, as shown in FIG. 55, a user can select a first bar 398 ofthe events graph. A log file window 340 displays the log file associatedwith the time period corresponding to the selected bar 398 of the eventsgraph. In some embodiments, multiple log files corresponding to the sametime period can be displayed concurrently and/or sequentially in the logfile window 340.

As shown in FIG. 56, in some embodiments, a user can save a selectedcombination of metrics, events, log files, and/or other overlaid data toa user dashboard for future review and/or monitoring.

In some embodiments, the user dashboard 378 illustrated in FIGS. 44-66can be used to investigate a cause of one or more service issues. Forexample, in one embodiment, a service interruption may occur thatimpacts a percentage of end-users in a production environment. Anoperational engineer (and/or other IT professional) can interact withthe user dashboard 378 to identify the root cause of the serviceinterruption. A specific use case is discussed herein with respect toFIGS. 44-56, although it will be appreciated that the user dashboard 378can be used to review, analyze, investigate, and/or otherwise interactwith one or more metrics to identify service anomalies, forecast servicerequirements, and/or perform additional IT tasks.

In some embodiments, the SPLUNK® ENTERPRISE system detects one or morenotable events in one or more monitored performance characteristics,such as a lower than expected transaction throughput. The SPLUNK®ENTERPRISE system can generate a communication, such as an e-mail, achat message, a text message, and/or other communication to one or moreusers who have selected transaction throughput as a monitored metric.For example, in some embodiments, an operations engineer has previouslyadded a throughput metric (or related metric) to their user dashboard.The user can access a user dashboard 378, for example, through asupplied link to review the notable event(s).

In some embodiments, when the user opens the user dashboard 378, ametric is displayed to the user and notable event can be identified withone or more identifiers. In some embodiments, a baseline visualizationis overlaid on the chart of the metric to show typical and/or forecastedbehavior of the metric. In some embodiments, a user can sort the metricaccording to one or more dimensions to isolate problems specific toindividual dimensions, such as individual servers or server clusters. Insome embodiments, if no numeric outliers are identified, a user caninvestigate degradations across an operational environment.

In some embodiments, a user can review common metrics for a similar oridentical time window as compared to the first metric to understand howthe environment has changed. For example, in some embodiments, a usercan add one or more additional metrics, such as a second metric, overthe same time period. In some embodiments, a historical view of thefirst metric and/or the second metric can additionally and/oralternatively be added to the user dashboard 378. In some embodiments,the additional and/or alternative metrics can be used to identify thebehavior change in the environment that resulted in the increase intransaction volume.

In some embodiments, the user can explore the multiple metrics and/orapply one or more aggregations of the selected metrics to diagnose acritical problem or to be proactive in isolating abnormal behaviors forany components in the environment. In some embodiments, the selection ofone or more metrics can allow a user to isolate a problem, such as, forexample, CPU usage being higher for a current concurrent workload thantraditionally experienced. In some embodiments, a user can use thecurrent and/or historical metrics to project additional capacity basedon typical peak workloads and current workloads.

In some embodiments, the user dashboard 378 is configured to allow auser to automatically add comments to a ticket generated that includesone or more of the selected metrics.

In some embodiments, the user dashboard 378 is configured to providequick visualization of one or more metric trends for any selected windowof time. Historical analysis and/or real-time analysis can be used toidentify production problems or analyze performance runs. In someembodiments, the SPLUNK® ENTERPRISE system is configured to allow a userto quickly access a user dashboard 378 and/or investigation interface366 by access, for example, a link in a ticket.

In some embodiments, the user dashboard 378 is configured to provideexploration and/or visualization of millions of time series data pointsfrom multiple data sources and provide a quickest time value ingeneration a visualization for each selected metric. In someembodiments, the context of a metric is configured to dynamically updatebased on a selected time window and one or more applied filtereddimensions associated with the metric.

In some embodiments, the user dashboard 378 and/or an investigationinterface 322 are configured to allow a user to review one or moreresources, such as, for example, CPU and Memory usage in an operationalenvironment. The user dashboard 378 is configured to provide a quickindicator of the count of one or more applications in a predeterminedtime window. A metric investigation process (such as the process 3400)can be used to filter all available metrics relevant to the selectedapplications and/or metrics related to components interacting with theselected applications. In some embodiments, the SPLUNK® ENTERPRISEsystem provides one or more visualizations to provide context withrespect to each selected metric.

In some embodiments, the user dashboard 378 and/or an investigationinterface 322 allow a user to quickly eliminate non-problem metrics orsystems and focus only on those metrics and/or systems that shownon-normal behavior. In some embodiments, aggregations can be applied tothe selected metrics to characterize metric trends (e.g., sudden,consistent, progressive, periodic, etc.) across one or more components.The user dashboard 378 allows a user to quickly compare how/if anymetrics have changed over a time period by selecting different timeperiods for the same metrics to isolate one or more problems.

In some embodiments, the user dashboard 378 is configured to allowanalysis of aggregate values to reduce investigation time. One or morealgorithms can be applied to the metrics and/or selected numericdatasets to highlight abnormal behavior and/or outliers. In someembodiments, a baseline visualization can be added to the metrics tohighlight normal usage during the time period to understand the contextof one or more outliers. Detecting and visualizing numeric outliers canprovide additional focus for analysis, such as specific data points ortime windows.

In some embodiments, the user dashboard 378 is configured to provideeasily accessible summary aggregation information, such as, for example,by hovering a cursor (or other input) over one or more points on ametric visualization. Additional information, such as a median, min,max, percentile (e.g., 10th, 50th, 90th, etc.), count of data points,and/or other summary aggregation information can be automaticallycalculated and displayed for selected metric values.

In some embodiments, multiple metric visualizations can be added to auser dashboard 378 to allow for correlation and impact analysis. Forexample, the impact that one or more metrics have on other metrics canbe investigated to determine the source of an increased resource usage.

In some embodiments, the user dashboard 378 is configured to allow auser to proactively monitor and analyze different metrics acrossdifferent technology domains based on a subject matter expertise toproactively monitor technologies and diagnose problems. In someembodiments, the user dashboard 378 can provide a list of technologiesthat can be selected by a user. When a user selects a technology, apredetermined group of metrics can be presented to the user for analysisand review. In some embodiments, a baseline is automatically added toeach of the predetermined group of metrics to eliminate the need for auser to manually compare trends of each metric over time. Additionalmetrics can be added to the user dashboard 378 by the user to furtherrefine and/or analyze performance trends. In some embodiments, a usercan generate a new dashboard 378 based on an investigation and/ormodification of an existing technology selection. The user dashboard canbe shared with additional users of the SPLUNK® ENTERPRISE system.

In some embodiments, a user can assign an alert to one or more metricsusing the user dashboard 378. For example, in some embodiments, an alertcan be added to a time series dashboard (i.e., a dashboard containingtime series metrics) to generate a message to the user if one or moremonitored metrics fall outside of a predetermined range. In someembodiments, the alert conditions include, but are not limited to,alerts such as: “Greater than,” “Lesser than”, and “equal to” athreshold or value and include normal, caution, or critical thresholds.In some embodiments, a status of an alert in the critical threshold (orthe caution threshold) is automatically displayed on a user dashboard378. In various embodiments, the thresholds can be static and/oradaptive thresholds.

In some embodiments, alerts can be sent to multiple users. Eventsuppression and/or notification can be configured and managed by singleuser of the SPLUNK® ENTERPRISE system and/or can be managed on auser-by-user basis.

In some embodiments, the SPLUNK® ENTERPRISE system is configured toprovide future forecasts for one or more selected components based onhistorical metrics. For example, in some embodiments, the SPLUNK®ENTERPRISE system can scale over a high volume of metric queries toadjust a component forecast as additional metric values are collected.

3.11.1. Real Time Searches

The disclosed embodiments include various enhancements that improve thespeed and performance of different types of searches. For example, theuse of tstats queries improves over traditional stats queries becauseprocessing may only look at the indexed fields of tsidx files. Hence,the tstats command can perform rapid statistical queries of indexedfields in tsidx files. In some embodiments, the indexed fields can befrom normal index data, tscollect data, or accelerated data models.Similarly, mstats commands can be used to improve the speed andperformance of statistical queries of metrics data as described furtherbelow.

The disclosed embodiments also include various enhancements that improvethe speed and performance of real-time searches. A real-time searchenables searching and displaying a continuous view of metrics ornon-metrics data as it streams into the data intake and query system.With real-time searching, data is searched before it is indexed. Forexample, real-time search results can be displayed in dashboards as thedata streams in. Unlike searches based on indexed data (e.g., historicalsearches), time bounds for real-time searches can continuously update.For example, a user can specify a time range that represents a slidingwindow of data, and the data intake and query system uses this window toaccumulate data that is viewable upon reaching the end of the window. Insome embodiments, a user can disable real-time searches for a particularindexer, or grant the ability to use real-time search to specific usersor roles. In some embodiments, a user can specify alerts that runcontinuously in the background for real-time searches.

In real-time searches, streams of pipelined data are received by indexprocessors, which can handle the data in different ways. The indexprocessors index the data in accordance with the techniques describedherein. The indexed data is the basis for subsequent historicalsearches. In addition to indexing data, for active real-time searches,separate real-time search processes connect the index processers to amanagement port, to route the data satisfying the real-time searches asstreams from the index processors to the management port. For example,an index processor may evaluate streaming events to determine whetherany of those events have a certain index value, source value, and IPvalue that satisfy an active real-time search.

The pipelined data typically includes numerous field/key values that canbe evaluated by the index processors for real time searches. Examplesinclude source, source type, host, or any arbitrary field/key. In thecontext of log data, a source may indicate the log file on which logdata is written to, a host may indicate the machine running anapplication from which the log data is generated, and a source type mayindicate a grouping used to, for example, identify configuration filesfor subsequent processing of the log data. In contrast, in the contextof metrics data, the source can indicate a metric name such as acomputing resource (e.g., CPU sensor) and its associated measurement(e.g., temperature).

The data satisfying real-time search criteria is communicated over acommunications link to a real-time communicator. This process acts as areal-time filter that reduces the amount of data communicated to thereal-time communicator. In some embodiments, the real-time communicatoris a process separate from the index processor that sends the identifieddata to the real-time communicator. In some embodiments, thecommunications link is HTTP-based or uses any standard network protocol.Specifically, data including values matching a predicate of a real-timesearch is queued and serialized by one or more index processors,communicated over communications links to one or more real-timecommunicators, de-serialized by the real-time communicators, queued andreported or communicated to a search head for reporting.

Hence, real-time communicators collect data satisfying real-time searchcriteria. In some embodiments, a real-time communicator can performaggregations or statistical functions on collected data and post theaggregates or statistical results as real-time search results. In someembodiments, a real-time communicator can communicate the collected datato a search head, which can aggregate the data with other collected dataor perform statistical operations on the collective data to obtainsearch results. The aggregated data or results of the statisticaloperations are then reported as search results.

In some embodiments, a number of real-time search processes can be runconcurrently by using indexed real-time searches, which lessen theimpact of performance on an indexer. An indexed real-time search runslike a historical search, but also continually updates with new data asit is recorded. An indexed real-time search can be used whenup-to-the-second accuracy is not needed because the results returned byindexed real-time searches lag behind a real-time search.

The amount of data being serialized by index processors can negativelyaffect the performance of real-time searches. As such, it is desirableto minimize the amount of data needing to be serialized and communicatedto a real-time communicator. The real-time filtering by the indexprocessor helps minimize what data is actually serialized andcommunicated to the real-time communicator. As such, the real-timesearch results can be populated with relevant data without having totransfer all streamed data by the network processors. Although thisreal-time filtering is computationally costly, the overall performanceof a real-time search is improved because less data is being serialized,communicated, and de-serialized.

The metrics store system 200 includes enhancements that further improvethe performance of real-time searches. In particular, real-time searchescan include enhancements that reduce overhead and can performstatistical queries completely in memory to reduce I/O processing. Theenhancements can improve individual and concurrent real-time searches.In some embodiments, the metrics store system 200 can also enablereal-time searching with backfilling powered by mstats to performstatistical queries on indexed metric data.

The streams of pipelined data received by index processors can befurther processed to reduce the amount of data serialized forcommunication to real-time communicators. Specifically, in addition toindexing data, the index processors or a separate summarizationprocessor can perform aggregation or statistical functions to create asummarization data structure that captures sufficient aggregate orstatistical data for reporting search results while reducing the amountof data being communicated to real-time communicators.

The real-time filtering by index processors reduces the amount of datathat needs to be communicated to the real-time communicators byidentifying data that satisfies real-time search criteria. The filtereddata is processed by index processors or separate summarizationprocessors to further reduce the amount of data needing to becommunicated to real-time communicators. For example, the filtered datacan be processed by aggregation or statistical functions to furtherreduce the amount of data that needs to be communicated. The resultingsummarized data is serialized, routed to a real-time communicator overthe communications link, and is de-serialized by the real-timecommunicator.

Thus, the real-time communicator can collect summarized data satisfyingreal-time search criteria. As a result, the real-time communicatorand/or a search head need not perform aggregations or statisticalfunctions on the data it collects. Instead, the real-time communicatorcan report the summarized data as real-time search results or, in thecontext of a distributed search, the search head implementingmap-reduced techniques can harmonize the summarized data with partialsearch results from other sources to obtain the final real-time searchresults.

In some embodiments, the disclosed embodiments can includeauto-aggregation functions for preselected metrics or any metrics data.For example, the auto-aggregation functions can aggregate metrics dataautomatically to respond quickly to real-time searches and/or historicalsearches. Thus, the enhanced processes disclosed herein for handlingreal-time search results is improved because the aggregation orstatistical operations can be performed in memory to reduce overhead andthe need to communicate data otherwise required for real-time searches.These disclosed techniques also improve scalability of real-timesearches as a result of lower overhead and I/O processing.

FIG. 57 is a flow diagram illustrating a method for performing real-timesearches according to some embodiments of the present disclosure.Although described in the context of metrics data, the methodillustrated in FIG. 57 can be implemented with any type of dataincluding time-indexed events. The method 5700 is performed, at least inpart, by a data intake and query system. Moreover, many or all of thesteps of the method 5700 are performed in real time.

In step 5702, the data intake and query system receives a real-timesearch query including search criteria. In step 5704, the data intakeand query system receives a stream of metrics. In some embodiments, thereal-time search query is automatically generated and executed withoutuser input as an auto-aggregation function.

In step 5706, a first process (e.g., index processor) can filter thestream of metrics to obtain filtered metrics satisfying the searchcriteria. In some embodiments, the metrics being evaluated by the indexprocessor are also indexed in the metrics store.

In step 5708, a second process (e.g., index process or summarizationprocessor) can create an in-memory summarization data structure based onthe plurality of filtered metrics. In some embodiments, thesummarization data structure includes aggregate or statistical dataderived from the plurality of filtered metrics.

In step 5710, the summarization data structure is communicated to athird process (e.g., real-time communicator). For example, in step 5712,the second process serializes the summarization data for communicationto the third process. The, in step 5714, the third process de-serializesthe received summarization data. In some embodiments, the summarizationdata is communicated from the second process to the third process overan HTTP-based communications link.

In step 5716, the third process can communicate the summarization datato a search head. In step 5718, the search head can post search resultsincluding the summarization data, for example, by causing a displaydevice to display the search results. In some embodiments, thesummarization data constitutes partial search results, which areaggregated by the search head with other partial search results toproduce final search results that satisfy the real-time search query.

3.11.2. Accelerated Searches of Metrics Data

To speed up certain types of metrics queries, some embodiments of thedata intake and query system can create “metrics acceleration tables,”which contain metrics data and/or data related to metrics data. The datacan include key values of metrics data. Examples of keys include metricnames, meta keys, dimensions, or measurements. A metrics accelerationtable may be populated as a result of a search query applied to metricsdata. The data intake and query system can then use the metricsacceleration table to accelerate subsequent queries related to resultsof the original search query.

The data intake and query system can accelerate subsequent metricsqueries by using data contained in the metrics acceleration table toreturn search results while avoiding processes otherwise required toobtain initial metrics search results. In other words, subsequentqueries take advantage of earlier queries by using the metricsacceleration table to skip processing steps of earlier queries. Forexample, the data intake and query system may receive a search query formetrics that have specified dimension values. A metrics accelerationtable produced in response to the search query can be used forsubsequent statistical queries about the metrics having the specifieddimension values.

The metrics acceleration tables are populated at search time. The basisfor the metrics acceleration tables are metric-series index (msidx)files that can be populated at index time. The msidx files may beself-contained files populated with key values extracted from ingestedmetrics to facilitate searching metrics data. Search queries can be morequickly processed by scanning the msidx files. In other words, the msidxfiles provide a rapid alternative compared to searching each metricindividually. The acceleration tables, which are based on the msidxfiles, accelerate subsequent queries related to search results ofearlier queries that used the msidx files to obtain the search results.As a result, the acceleration tables provide a further rapid alternativecompared to using the msidx files.

FIG. 58 is a block diagram illustrating examples of a msidx file,optional companion journal, and an acceleration table used to processqueries for metrics data according to some embodiments of the presentdisclosure. In some embodiments, the msidx file 400 can associate keyvalues of metrics with references to locations of the metrics stored inan optional companion journal 402. For example, at index time, ingestedmetrics can be processed to extract key values (e.g., meta values, userdefined values, measure values). The msidx file 400 can be populatedwith the extracted key values, and map the key values to the metricsmaintained in the companion journal 402. Then, in response to a query,the msidx file 400 is searched for data satisfying query criteria, andmetrics or related data can be extracted from the companion journal 402and returned as query results. The data from the companion journal 402may be extracted in accordance with configuration files for identifiedmetrics. For example, the configuration files may define extractionrules that are specific to a source or source type of metric, and thoseextraction rules can be used to extract data from the metrics.

In some embodiments, each “bucket” of metrics includes its own msidxfile. In some embodiments, each bucket contains its own companionjournal. As such, processing a search query may require scanning themsidx files of multiple buckets to obtain search results. In someembodiments, to speed up searches, bloom filters can be used to narrowthe set of msidx files that must be searched to obtain search results.

An advantage of maintaining the separate companion journal 402 is thatthe msidx file can be more compact compared to the companion journal 402because it only includes some data of the companion journal 402 and/orreferences to data contained in the companion journal 402. This isparticularly advantageous when the companion journal 402 contains largeamounts of raw data. However, in some embodiments, the companion journal402 is unnecessary to process queries if all the relevant metrics datais contained in the msidx file 400. For example, unlike events thatinclude raw data, metric data is typically structured data such that itexcludes raw data. As a result, the data intake and query system wouldnot need to use the optional companion journal 402 to process queries ifthe msidx file contains all the data satisfying query results.

The structure and contents of a msidx file can facilitate rapidprocessing of metrics queries. In some embodiments, a msidx file isstructured to include distinct sections (e.g., distinct portions of themsidx file). For example, a msidx file may include a section thatcontains an array of time values for metrics data, and/or a section thatcontains an array of metrics identifiers and location information forthe metrics stored in a companion journal. However, again, includingreferences to metrics in a companion journal may be unnecessary if allthe meaningful metrics data is included in a msidx file.

Structuring a msidx file to include distinct sections of metrics datacan facilitate processing queries by limiting the sections that aresearched in response to a query and mapping the searched sections toother sections of the msidx file that contain query results or dataindicative of the query results. For example, the msidx file 400includes a lexicon section 404 (“lexicon 404”) that contains key valuesextracted from metrics data at index time. For example, the lexicon 404may include each key values for required dimensions, optionaldimensions, user specified dimensions, meta keys, keywords, orcombinations thereof. In response to a query, the lexicon 404 may be theonly section of the msidx file 400 that is searched for data indicativeof results. The lexicon 404 can be mapped to other sections of the msidxfile 400 to retrieve the results.

The msidx file 400 includes a distinct measurements section 406. Themeasurements section 406 includes all of the numerical values of themetrics data. Although the lexicon 404 could include all these numericalvalues, the cardinality of the numerical values is so great that itcould bloat the lexicon 404 and reduce the efficiency of searching thelexicon 404. For example, each measurement can be a precise floatingpoint numerical value with multiple decimal places. As a result, therewould be very few repeating measurement values among the metrics, exceptpossibly for a value such as zero. Moreover, in practice, a user wouldrarely search for a specific measurement value. As such, keeping themeasurement values in the lexicon 404 would have little benefit andcould hinder searches. As such, the msidx file 400 has a distinctsection that contains an array of all the numerical values extractedfrom metrics data at index time and recorded in the measurements section406 to overcome these drawbacks. For example, the measurements section406 may include a row for each numerical value entry of ingestedmetrics. In some embodiments, maintaining the numerical values in aseparate array allows for implementing compression techniques such asdelta-of-delta timestamps and XOR-based compression of the floatingpoint values to reduce storage requirements and enable storing datain-memory, reducing latency, and improving query throughput.

The msidx file 400 may also include a posting section 408 (“postings408”) that maps key values of the lexicon 404 to other sections of themsidx file 400 such as the measurements section 406. The sections of themsidx file 400 can be structured to map entries in one section toentries in another section. In particular, row entries of one sectioncan correspond to row entries of another section. For example, thelexicon 404 may include N entries in N rows. The postings 408 may alsoinclude N entries in N rows such that the kth row of the lexicon 404corresponds to the kth row of the postings 408. As such, values ofdifferent sections that correspond to each other can be inferred fromthe structure and order of the entries in those sections.

In some embodiments, entries of sections may contain explicit referencesto other entries in other sections of the msidx file 400. For example,the lexicon 404 can include N entries in N rows, and the postings 408can include N entries in N rows, each including an identifier to anumerical value of the measurements 406. In some embodiments, thepostings 408 may include references to metric identifiers and/orreferences to locations of corresponding metrics stored in the journal.Thus, the structure and/or content of the msidx file 400 and itssections can create implicit and/or explicit paths to metrics datacontained in the msidx file 400 or elsewhere (e.g., the companionjournal 402).

During search time, a query may include criteria that specifies keyvalues (e.g., user defined dimension value pairs) contained in thelexicon 404 of the msidx file 400. The lexicon 404 is scanned toidentify the specified key values. The relative locations of lexiconentries that contain the specified key values can be used to identifycorresponding entries in the postings 408, which can include referencesto numerical values of the measurement 406 or metric identifiers inanother section (not shown).

For example, the criteria of a search query may include the value“device.voltage” for a “name” dimension. The lexicon 404 of the msidxfile 400 can be searched for the specified dimension values. The secondentry of the lexicon 404 may include a specified dimension values, andthe corresponding second entry of the postings 408 may identify threemetrics taken at times 0, 10, and 20 that have a value of“device.voltage” for the name dimension. The measurements identifiers inthe second entry of the postings 408 can be used to identify thecorresponding numerical values of 0.7, 0.8, and 1.2 of the measurements406. As such, the numerical values that satisfy the query can beretrieved using the msidx file 400. Thus, when the data intake andsystem receives queries, it will scan the msidx files 400 for criteriawithout needing to search a companion journal file.

In some embodiments, the process for searching metrics detailed above isrepeated for each and every query. Hence, even though the use of msidxfiles enhances searching by avoiding the need to search a journal ofmetrics, using the msidx files for searching over the same metrics canbe inefficient. For example, a first search query may specify a sourcename, and msidx files can be used to retrieve metric values associatedwith that source name. A second search may specify a statisticalanalysis to be performed of metrics that contain the specified sourcename of the first search query. As such, performing the second querywould require at least the same steps performed for the first searchquery, and additional steps to complete the statistical process.Accordingly, performing the second subsequent query is inefficientbecause it fails to take advantage of the execution of the first query.

To speed up certain types of metrics queries, acceleration tables thatcontain metrics data and/or data related to the metrics data can becreated from earlier search queries based on msidx files. FIG. 58includes an example of an acceleration table 410. The mechanism thatcreates the acceleration table 410 can be initiated automatically ormanually by a user per search, and/or per bucket. For example, a usercan set a data model that can automatically generate and useacceleration tables to perform specialized searches. In another example,a user can submit a command through a user interface to accelerate queryprocessing by using acceleration tables. Then, upon receiving searchqueries, the system can generate and subsequently scan accelerationtables to accelerate searches. For example, a user can append a firstSPL search command with a second SPL command causing the system tooperate on an acceleration table created by the first SPL searchcommand, to obtain search results that avoid consulting the msidx files,configuration files, extraction rules, etc.

At search time, the acceleration table 410 is generated based on msidxfile 400. Specifically, the acceleration table 410 is populated withsearch results including key values for a set of metrics. The searchresults are obtained based on the msidx file 400 in accordance with thequery process above. The acceleration table 410 is enriched with otherkey values that were not part of the search results. The other keyvalues were obtained from the same set of metrics. Hence, the size ofthe acceleration table 410 depends on the key values included in thesearch results and other key values that were not included in the searchresults. The other key values used to enrich the acceleration table 410are identified using configuration files of the set of metrics. Asindicated above, different types of data may be associated withdifferent configuration files that define different extraction rulesused to extract values from that data. Hence, different configurationfiles may be processed to populate the acceleration table 410.

In particular, the configuration files for metrics identified at searchtime can be used to populate an acceleration table by applying theextraction rules of the configuration files to the identified metrics.For example, the data intake and query system could retrieve differentconfiguration files for different source types of identified metrics.Some or all the extraction rules defined by the configuration files canbe used to extract some or all the key values that are extractable. Theacceleration table 410 is thus, for example, populated with searchresults and all other key values associated with the metrics data of thesearch results.

As shown, the acceleration table 410 can have a columnar structure wheremetrics data is stored in columns instead of rows. Specifically, eachcolumn may correspond to a key of the metrics identified at search time.In some embodiments, the acceleration table 410 may include cells thatare empty. For example, the identified metrics may be associated withdifferent source types that have different configuration files definingdifferent extraction rules. As a result, some cells of the accelerationtable 410 are empty because different extraction rules are not relevantto all the identified metrics. Moreover, since the acceleration table410 includes at least some columns that can map to the rows of the msidxfile 400, the msidx file 400 itself can be derived from the accelerationtable 410, if desired.

The contents of the acceleration table 410 form a lexicon, which can bescanned at search time to process certain types of queries. Since theacceleration table 410 includes all the key values for a set of metrics,it does not need to include references to the metrics data recorded inthe msidx file 400 or the companion journal 402. Thus, scanning theacceleration table 410 to obtain query results eliminates the need toscan the msidx file 400 and/or the companion journal 402. As a result,processing queries related to metrics data contained in the accelerationtable 410 is quicker because there is no need to consult the msidx file,the companion journal 402, configuration files, extraction rules, etc.

Specifically, the data intake and query system can process subsequentqueries quickly by using data contained in the acceleration table 410rather than searching the metrics data all over again in the msidx file400 or the companion journal 402 via the msidx file 400. For example, auser may seek to perform an aggregation or statistical analysis ofmetrics that include particular values in particular keys. To this end,the system can examine entries in the acceleration table 410 to performthe statistical analysis on the specific values in the specific keyswithout having to examine the individual metrics or perform dataextractions at search time. Thus, rather than perform another search andextraction process involving the msidx file 400 or the companion journal402, the acceleration table can be used alone.

For example, criteria of a first search query may specify a“device.voltage” value for a “name” dimension. The data intake and querysystem could return metric data that satisfies the search query andtransparently populate an acceleration table with the search results andall other key values of metrics that include the “device.voltage” valuein the “name” dimension. Then, the data intake and query system mayreceive a query specifying criteria including a count of metrics thathave a “device.voltage” value for the “name” dimension.

Without the acceleration table 410, the data intake and query systemwould need to search and/or extract metrics data satisfying the criteriaand then perform a count of specified key values to obtain searchresults. However, with the acceleration table 410, the data intake andquery system can examine entries in the acceleration table 410 to countinstances of “device.voltage” in the “name” dimension without having toexamine the msidx file 400 or the individual metrics recorded on thecompanion journal 402, or perform data extractions at search time.

In some embodiments, the data intake and query system can maintain aseparate acceleration table for each bucket that stores metrics for aspecific time range. A bucket-specific acceleration table includesentries for specific key value combinations that occur in metrics in thespecific bucket. In some embodiments, the data intake and query systemcan maintain a separate acceleration table for each indexer. Theindexer-specific acceleration table includes entries for metrics in thatare managed by the specific indexer. Indexer-specific accelerationtables may also be bucket-specific. However, the disclosed embodimentsare not so limited. Instead, acceleration tables can be defined based onany range or parameter used to limit a search operation.

In some embodiments, an acceleration table can include references tometrics from which key values can be extracted. If the data intake andquery system needs to process all metrics that have a specific key-valuecombination, the data intake and query system can use the references inthe acceleration table entry to directly access the metrics in thejournal. For example, when the acceleration tables do not cover all ofthe metrics that are relevant to a search query, the system can use theacceleration tables to obtain partial results covered by accelerationtables, but the system may also have to search through metrics data thatis not covered by the acceleration tables to produce the remainingresults. These remaining results can then be combined with the partialresults to produce a final set of results for the query. In someembodiments, the msidx files or acceleration tables can be cached in thememory for a faster search.

FIG. 59 is a flow diagram illustrating a method for performing metricqueries according to some embodiments of the present disclosure. In step5902, the data intake and query system ingests data including metrics(e.g., semi-structured or structured metrics data). In some embodiments,the metrics are received by the data intake and query system over acomputer network from remote computer systems. Each metric can includenumerous key values and at least one or only one numerical value (e.g.,a floating point value) indicative of a measured characteristic of acomputing resource. In some embodiments, the characteristic is autilization of a processor, a temperature of an electronic component, ora voltage reading of an electronic component.

In step 5904, the data intake and query system populates a first portionof a metric-series index (msidx) file with the key values and a secondportion of the msidx file with every numerical value indicative of ameasured characteristic. The first portion may be a lexicon section,which is distinct from a measurements (e.g., second) section.

In some embodiments, the metrics are multi-dimensional metrics, whereeach metric has a number of dimensions including required dimensionsthat must have values and/or optional dimensions that can have values.Examples of the required dimensions include a time dimension including avalue indicative of when a measured characteristic was measured, and aname dimension including a value indicative of a source of the measuredcharacteristic. Examples of optional dimensions include a hostdimension, a manufacturer dimension, or a model dimension. In someembodiments, the optional dimensions were specified by a user before orafter ingestion of the metrics. Moreover, in some embodiments, at leastsome of the numerical values are indicative of a time series of measuredcharacteristics of the same computing resource.

In step 5904, the data intake and query system receives a query,including criteria. In some embodiments, the query is input by a userand expressed as an SPL command. In some embodiments, the criteria mayinclude values for required or optional dimensions. In step 5906, thedata intake and query system evaluates the query by applying thecriteria to the lexicon of the msidx file to obtain query resultsindicative of metrics that satisfy the criteria. For example, in step5910, the query results are obtained by extracting data from the metricsstored in a journal distinct and separate from the msidx file, whereeach location of each metric stored in the journal is referenced in themsidx file. In another example, the query results are obtained from themsidx file without retrieving data from the journal storing the metrics.

In some embodiments, the query may specify a desired correlationoperation between metrics and non-metrics data. For example, in step5912, the data intake and query system can extract field values fromtime-indexed events that also satisfy search criteria and correlate theextracted field values and the metrics query results to obtaincorrelation results. Then, in step 5914, the query results (orcorrelation results) or data indicative of the query results (orcorrelation results) can be displayed on a display device.

In some embodiments, an acceleration table is produced to acceleratesubsequent queries. In step 5916, the data intake and query systempopulates an acceleration table with the previous (e.g., first) queryresults obtained and additional key values of the metrics that satisfythe previous (e.g., first) criteria as defined in at least oneconfiguration file associated with the metrics that satisfy the firstcriteria.

In step 5918, the data intake and query system receives another (e.g.,second) query including other (e.g., second) criteria having a scopeincluding the metrics that satisfied the previous (e.g., first) query.In some embodiments, the second query can be a second SPL command thatappends the previous (e.g., first) SPL command. For example, the firstSPL command can be a search command for certain metrics, and the secondSPL command can be an aggregation or statistical command including thesame certain metrics.

In step 5920, the data intake and query system can evaluate the secondquery by applying the second criteria to the acceleration table toobtain second query results without applying the second criteria to themsidx file. Lastly, in step 5922, the second query results or dataindicative of the second query results can be displayed on a displaydevice.

4.0. COMPUTING SYSTEM ARCHITECTURE

FIG. 60 is a block diagram illustrating a high-level example of ahardware architecture of a computing system in which an embodiment maybe implemented. For example, the hardware architecture of a computingsystem 450 can be used to implement any one or more of the functionalcomponents described herein (e.g., metrics ingestion component 202,metrics catalog and search component 204, metrics analysis component206, metrics sharing component 208, or metrics store component 210). Thecomputing system 450 can also be used to implement any of a forwarder,indexer, search head, data store, or a computing resource. In someembodiments, one or multiple instances of the computing system 450 canbe used to implement the technologies described herein, where multiplesuch instances can be coupled to each other via one or more networks.

The processes and logic flows described in this specification can beperformed by one or more programmable processors executing one or morecomputer programs to perform functions by operating on input data andgenerating output. For example, the computing system 450 includes one ormore processing devices 452, one or more memory devices 454, one or morecommunication devices 456, one or more input/output (I/O) devices 458,and one or more mass storage devices 460, all coupled to each otherthrough an interconnect 462.

The interconnect 462 may be or include one or more conductive traces,buses, point-to-point connections, controllers, adapters, and/or otherconventional connection devices. Each of the processing devices 452controls, at least in part, the overall operation of the processing ofthe computing system 450 and can be or include, for example, one or moregeneral-purpose programmable microprocessors, digital signal processors(DSPs), mobile application processors, microcontrollers, special purposelogic circuitry, e.g., a field programmable gate array (FPGA) or anapplication specific integrated circuit (ASIC), or the like, or acombination of such devices.

Each of the memory devices 454 can be or include one or more physicalstorage devices, which may be in the form of random access memory (RAM),read-only memory (ROM) (which may be erasable and programmable), flashmemory, miniature hard disk drive, or other suitable type of storagedevice, or a combination of such devices. Each mass storage device 460can be or include one or more hard drives, digital versatile disks(DVDs), flash memories, or the like. Each memory device 454 and/or massstorage device 460 can store (individually or collectively) data andinstructions that configure the processing device(s) 452 to executeoperations to implement the techniques described above.

Processors suitable for the execution of a computer program include, byway of example, both general and special purpose microprocessors, andany one or more processors of any kind of digital computer (e.g.,processing devices 452). Generally, a processor will receiveinstructions and data from a read-only memory or a random access memoryor both. The essential elements of a computer are a processor forperforming instructions and one or more memory devices for storinginstructions and data. Generally, the computer system 450 will alsoinclude, or be operatively coupled to receive data from or transfer datato, or both, one or more mass storage devices for storing data, e.g.,magnetic, magneto optical disks, or optical disks. However, a computerneed not have such devices.

Each communication device 456 may be or include, for example, anEthernet adapter, cable modem, Wi-Fi adapter, cellular transceiver,baseband processor, Bluetooth or Bluetooth Low Energy (BLE) transceiver,or the like, or a combination thereof. Depending on the specific natureand purpose of the processing devices 452, each I/O device 458 can be orinclude a device such as a display (which may be a touch screendisplay), audio speaker, keyboard, mouse or other pointing device,microphone, camera, etc. Note, however, that such I/O devices 458 may beunnecessary if the processing device 452 is embodied solely as a servercomputer.

The computing system 450 can include clients or servers. A client andserver are generally remote from each other and typically interactthrough a communication network. The relationship of client and serverarises by virtue of computer programs running on the respectivecomputers and having a client-server relationship to each other. In thecase of a client device, the communication devices(s) 456 can be orinclude, for example, a cellular telecommunications transceiver (e.g.,3G, LTE/4G, 5G), Wi-Fi transceiver, baseband processor, Bluetooth or BLEtransceiver, or the like, or a combination thereof. In the case of aserver, the communication device(s) 456 can be or include, for example,any of the aforementioned types of communication devices, a wiredEthernet adapter, cable modem, DSL modem, or the like, or a combinationof such devices.

Embodiments of the subject matter and the functional operationsdescribed in this specification can be implemented in digital electroniccircuitry, or in computer software, firmware, or hardware, including thestructures disclosed in this specification and their structuralequivalents, or in combinations of one or more of them. Embodiments ofthe subject matter described in this specification can be implemented asone or more computer program products, i.e., one or more modules ofcomputer program instructions encoded on a computer readable medium forexecution by, or to control the operation of, data processing apparatus.

A software program or algorithm, when referred to as “implemented in acomputer-readable storage medium,” includes computer-readableinstructions stored in a memory device (e.g., memory device(s) 454). Aprocessor (e.g., processing device(s) 452) is “configured to execute asoftware program” when at least one value associated with the softwareprogram is stored in a register that is readable by the processor. Insome embodiments, routines executed to implement the disclosedtechniques may be implemented as part of OS software (e.g., MICROSOFTWINDOWS® or LINUX®) or a specific software application, algorithmcomponent, program, object, module, or sequence of instructions referredto as “computer programs.”

The computer readable medium can be a machine readable storage device, amachine readable storage substrate, a memory device, a composition ofmatter effecting a machine readable propagated signal, or a combinationof one or more of them. The term “data processing apparatus” encompassesall apparatus, devices, and machines for processing data, including byway of example a programmable processor, a computer, or multipleprocessors or computers. The apparatus can include, in addition tohardware, code that creates an execution environment for the computerprogram in question, e.g., code that constitutes processor firmware, aprotocol stack, a data store management system, an operating system, ora combination of one or more of them, a propagated signal is anartificially generated signal, e.g., a machine generated electrical,optical, or electromagnetic signal, that is generated to encodeinformation for transmission to suitable receiver apparatus.

A computer program (also known as a program, software, softwareapplication, script, or code) typically includes one or moreinstructions set at various times in various memory devices of acomputing device, which, when read and executed by at least oneprocessor (e.g., processing device(s) 452), will cause a computingdevice to execute functions involving the disclosed techniques. In someembodiments, a carrier containing the aforementioned computer programproduct is provided. The carrier is one of an electronic signal, anoptical signal, a radio signal, or a non-transitory computer-readablestorage medium (e.g., the memory device(s) 454).

A computer program can be written in any form of programming language,including compiled or interpreted languages, and it can be deployed inany form, including as a standalone program or as a module, component,subroutine, or other unit suitable for use in a computing environment. Acomputer program does not necessarily correspond to a file in a filesystem. A program can be stored in a portion of a file that holds otherprograms or data (e.g., on or more scripts stored in a markup languagedocument), in a single file dedicated to the program in question, or inmultiple coordinated files (e.g., files that store one or more modules,sub-programs, or portions of code). A computer program can be deployedto be executed on one computer or on multiple computers that are locatedat one site or distributed across multiple sites and interconnected by acommunication network.

The computer system 450 can be embedded in another device, e.g., amobile telephone, a personal digital assistant (PDA), a mobile audioplayer, a Global Positioning System (GPS) receiver, to name just a few.Computer readable media suitable for storing computer programinstructions and data include all forms of nonvolatile memory, media,and memory devices, including by way of example semiconductor memorydevices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks,e.g., internal hard disks or removable disks; magneto optical disks; andCD ROM and DVD ROM disks. The processor (e.g., processing devices 452)and the memory (e.g., memory device 454) can be supplemented by, orincorporated in, special purpose logic circuitry.

To provide for interaction with a user, architecture provider orreviewer, embodiments of the subject matter described in thisspecification can be implemented with a display device of the I/Odevices 458, e.g., a CRT (cathode ray tube) to LCD (liquid crystaldisplay) monitor, for displaying information to the user and a keyboardand a pointing device, e.g., a mouse or a trackball, by which the usercan provide input to the computer. Other kinds of I/O devices 458 can beused to provide for interaction with a user, architecture provider orreviewer as well; for example, feedback provided to the user can be anyform of sensory feedback, e.g., visual feedback, auditory feedback, ortactile feedback; and input from the user, architecture provider orreviewer can be received in any from, including acoustic, speech, ortactile input.

In some embodiments, the computing system 450 can include a back endcomponent (not shown), e.g., as a data server, or that includes amiddleware component, e.g., an application server, or that includes afront end component, e.g., a client computer having a graphical userinterface (e.g., metrics-aware UI) or a Web browser through which a usercan interact with an implementation of the subject matter described inthis specification, or any combination of one or more such back end,middleware, or front end components. The components of the system can beinterconnected by any form or medium of digital data communication,e.g., a communication network. Examples of communication networksinclude a local area network (“LAN”) and a wide area network (“WAN”),e.g., the Internet.

Any or all of the features and functions described above can be combinedwith each other, except to the extent it may be otherwise stated aboveor to the extent that any such embodiments may be incompatible by virtueof their function or structure, as will be apparent to persons ofordinary skill in the art. Unless contrary to physical possibility, itis envisioned that (i) the methods/steps described herein may beperformed in any sequence and/or in any combination, and (ii) thecomponents of respective embodiments may be combined in any manner.

Although the subject matter has been described in language specific tostructural features and/or acts, it is to be understood that the subjectmatter defined in the appended claims is not necessarily limited to thespecific features or acts described above. Rather, the specific featuresand acts described above are disclosed as examples of implementing theclaims, and other equivalent features and acts are intended to be withinthe scope of the claims.

While this specification contains many specifics, these should not beconstrued as limitations on the scope of the invention or of what may beclaimed, but rather as descriptions of features specific to particularembodiments of the invention. Certain features that are described inthis specification in the context or separate embodiments can also beimplemented in combination in a single embodiment. Conversely, variousfeatures that are described in the context of a single embodiment canalso be implemented in multiple embodiments separately or in anysuitable sub-combination. Moreover, although features may be describedabove as acting in certain combinations and even initially claimed assuch, one or more features from a claimed combination can in some casesbe excised from the combination, and the claimed combination may bedirected to a sub-combination or variation of a sub-combination.

Similarly, while operations are depicted in the drawings in a particularorder, this should not be understood as requiring that such operationsbe performed in the particular order shown or in sequential order, orthat all illustrated operations be performed, to achieve desirableresults. In certain circumstances, multitasking and parallel processingmay be advantageous. Moreover, the separation of various systemcomponents in the embodiments described above should not be understoodas requiring such separation in all embodiments, and it should beunderstood that the described program components and systems cangenerally be integrated together in a single software product orpackaged into multiple software products.

Thus, particular embodiments of the invention have been described. Otherembodiments are within the scope of the following claims. For example,the actions recited in the claims can be performed in a different orderand still achieve desirable results.

What is claimed is:
 1. A method, comprising: populating, by a dataintake and query system, an index of a metrics store with a plurality ofmetrics, each metric including a measure value; receiving, by the dataintake and query system, a specified condition related to the pluralityof metrics; cataloging, by the data intake and query system, metadatarelated to the specified condition in an in-memory metrics catalog;receiving, by the data intake and query system, a search query includingsearch criteria; evaluating, by the data intake and query system, thesearch query by applying the search criteria to the metadata of themetrics catalog to obtain results that satisfy the search criteria; andcausing display, on a display device, of the results or data indicativeof the results.
 2. The method of claim 1, further comprising: calling,by the data intake and query system, an application programminginterface (API) to retrieve metrics data from the metrics store, themetrics data being cataloged in the in-memory metrics catalog.
 3. Themethod of claim 1, wherein the plurality of metrics are received by thedata intake and query system over a computer network from a plurality ofremote computer systems.
 4. The method of claim 1, wherein the query isinput by a user via a user interface rendered on the display device, andwherein the results or the data indicative of the results is rendered onthe user interface.
 5. The method of claim 1, wherein the metrics storeis not an in-memory metrics store.
 6. The method of claim 1, wherein themetrics store resides in non-volatile memory, and wherein the resultsare obtained by retrieving metrics data only from the metrics catalog.7. The method of claim 1, wherein the metrics store resides innon-volatile memory, and wherein the results are obtained by retrievingmetrics data in the metrics store.
 8. The method of claim 1, wherein atleast some of the metadata is user specified metadata.
 9. The method ofclaim 1, wherein the metadata includes user specified metadataindicative of at least one condition causing the metrics catalog toautomatically retrieve metrics data from the metrics store.
 10. Themethod of claim 1, wherein the metadata includes user specified metadataindicative of a threshold of a measure value, a range of a measurevalue, or preferred measure value for a metric.
 11. The method of claim1, wherein the metadata defines a condition related to a metric in themetrics store, and the occurrence of the condition causes the metricscatalog to display an alert on the display device.
 12. The method ofclaim 1, wherein the search query is input by a user and expressed in apipelined search language.
 13. The method of claim 1, wherein the indexincludes a plurality of dimensions, and wherein each of the plurality ofdimensions is either a required dimension or an optional dimension, eachmetric includes a value for each required dimension, and only some ofthe plurality of metrics include values for some optional dimensions.14. The method of claim 1, wherein the index includes a plurality ofdimensions, and the plurality of dimensions includes a user specifieddimension.
 15. The method of claim 1, wherein each metric has only onemeasure value, and the measure value is a floating point value.
 16. Themethod of claim 1, wherein the plurality of metrics are received by thedata intake and query system over a computer network from a plurality ofremote computer systems, and where each metric is semi-structured dataor structured data.
 17. The method of claim 1, wherein the measure valueis a utilization of a processor, a temperature of an electroniccomponent, or a voltage reading of an electronic component.
 18. Themethod of claim 1, wherein the search criteria has a scope includingmetrics data and non-metrics data, and wherein the results includemetrics data and non-metrics data.
 19. The method of claim 1, whereinthe metadata includes user specified metadata causing a metric to appeardeleted or edited from the metric store.
 20. The method of claim 1,wherein the metadata includes user specified metadata causing a metricto appear with a unit value different from a unit value of the metric inthe metric store.
 21. The method of claim 1, wherein the metadataincludes user specified metadata indicative of a relationship betweentwo or more metrics of the metrics store.
 22. The method of claim 1,wherein the plurality of metrics are received by the data intake andquery system over a computer network from a plurality of remote computersystems.
 23. The method of claim 1, wherein the query is input by a uservia a user interface rendered on the display device, and wherein theresults or the data indicative of the results is rendered on the userinterface.
 24. The method of claim 1, wherein the metrics store is notan in-memory metrics store.
 25. The method of claim 1, wherein theresults are obtained by retrieving metrics data only from the metricscatalog.
 26. A method, comprising: storing, by a data intake and querysystem, a plurality of metrics in an index of a metrics store residingin non-volatile memory, the index including a plurality of dimensionsand a measure for each metric; receiving, by the data intake and querysystem, a specified condition related to the plurality of metrics storedin the index of the metrics store; cataloging, by the data intake andquery system, metadata related to the specified condition in a metricscatalog residing in volatile memory, wherein some of the metadata isuser specified and some of the metadata is derived from the plurality ofmetrics stored in the metrics store; receiving, by the data intake andquery system, a search query including search criteria; evaluating, bythe data intake and query system, the search query by applying thesearch criteria to the metadata of the metrics catalog to obtain resultswithout accessing the plurality of metrics of the metrics store; anddisplaying, on a display device, the results or data indicative of theresults.
 27. The method of claim 26, further comprising: calling, by thedata intake and query system, an application programming interface (API)to retrieve metrics data from the metrics store, the metrics data beingcataloged in the metrics catalog.
 28. The method of claim 26, whereinthe results are obtained by retrieving metrics data from the metricsstore.
 29. The method of claim 26, wherein at least some of the metadatais user specified metadata.
 30. A data intake and query system,comprising: a processor; and memory containing instructions that, whenexecuted by the electronic device, cause the data intake and querysystem to: populate an index of a metrics store with a plurality ofmetrics, each metric including a measure value; receive a specifiedcondition related to the plurality of metrics of the index of themetrics store; catalog metadata related to the specified condition in anin-memory metrics catalog; receive a search query including searchcriteria; evaluate the search query by applying the search criteria tothe metadata of the metrics catalog to obtain results that satisfy thesearch criteria; and cause the results or data indicative of the resultsto be displayed on a display device.